Why Replace orafce with orafce_no_c

orafce_no_c is a pure PL/pgSQL and SQL reimplementation of a substantial subset of orafce — the widely-used PostgreSQL extension that emulates a slice of Oracle's built-in functions and packages (DECODE, NVL, INSTR, TO_CHAR, business-day calendars, DBMS_OUTPUT, and much more), to smooth an Oracle-to-PostgreSQL migration.

Real orafce ships as compiled C code. That works fine on a self-managed server, but it creates a hard requirement: filesystem access to the PostgreSQL server's own extension directory, so a .control file and shared library can be placed there before CREATE EXTENSION orafce will work. Most managed and cloud PostgreSQL offerings — and plenty of tightly-locked-down self-managed environments — do not grant that access at all.

orafce_no_c removes that requirement entirely. There is no C code anywhere in this project. Every ported function is plain PL/pgSQL or SQL, installable two ways:

• As a genuine CREATE EXTENSION, if you do have filesystem access — a drop-in make install away.
• As a single SQL script you run with psql -f, with no privileged step at all, for everywhere else.

Both paths install the exact same functions with the exact same behavior — see the Installation book for both.

What you're trading for that portability

Not everything in real orafce can be reproduced without C — a handful of packages need genuine OS-level or shared-memory capabilities (cross-session signaling, raw filesystem I/O, dynamic bind-variable typing) that PL/pgSQL structurally cannot do. 10 of orafce's 15 packages are fully included; the other 5 are excluded outright, each for a specific, documented reason — see the Compatibility chapters for the full breakdown.

Within the packages that are included, everything was built and validated the same way: every ported function was tested side-by-side against the real, compiled orafce C extension — installed in the same database under a renamed schema — and asserted to match exactly, across PostgreSQL 14 through 18. Where a deliberate behavioral choice had to be made (a handful of cases — a platform-dependent random-number generator, a couple of confirmed real-orafce bugs, a GUC that requires C to implement), it's documented in detail in the Differences book, so you can decide for yourself whether it matters for your use case.

Who this is for

If you're migrating an Oracle-derived PostgreSQL application off real orafce — because you're moving to a managed/cloud database, because you can't get a C toolchain approved, or simply because you'd rather not maintain a compiled extension — orafce_no_c is meant to be a safe, thoroughly-tested replacement for the parts of orafce it covers. The next chapter shows you how to find out, precisely, which parts of orafce your own code actually uses, before you commit to switching.

Continue to Finding orafce Usage in Your Code.