Compatibility: Excluded Packages¶
The 5 packages below are not included in orafce_no_c at all — nothing in them converts. Each is excluded for a genuine, structural reason (a C-only OS or shared-memory capability), not for lack of effort. See How to Read These Tables for what the columns mean.
dbms_alert — cross-session event signaling¶
Cross-session event signaling needs a shared-memory registry of subscribed sessions plus a condition-variable-based blocking wait (register, waitany, waitone), and a deferred-until-commit write into that shared memory (signal/_signal) — none of which has a PL/pgSQL or SQL equivalent, since one backend cannot block until another backend writes to shared state without dropping into C. The only function without a direct C requirement, set_defaults, is a stub that just raises "not supported" and has no purpose without the rest of the package.
| Function | Includes C | Is Converted |
|---|---|---|
| dbms_alert._signal | Y | N |
| dbms_alert.register | Y | N |
| dbms_alert.remove | Y | N |
| dbms_alert.removeall | Y | N |
| dbms_alert.set_defaults | Y | N* |
| dbms_alert.signal | Y | N |
| dbms_alert.waitany | Y | N |
| dbms_alert.waitone | Y | N |
dbms_pipe — cross-session message passing¶
Cross-session message passing needs the same shared-memory pipe registry and condition-variable-based blocking send/receive as dbms_alert, which PL/pgSQL cannot do. The message pack/unpack and buffer bookkeeping functions are individually reimplementable in PL/pgSQL, but they exist only to prepare messages for send_message or consume messages from receive_message — both C-only — so converting them in isolation would just produce message serialization that can never actually be sent or received.
| Function | Includes C | Is Converted |
|---|---|---|
| dbms_pipe.__list_pipes | Y | N |
| dbms_pipe.create_pipe | Y | N |
| dbms_pipe.next_item_type | Y | N* |
| dbms_pipe.pack_message | Y | N* |
| dbms_pipe.purge | Y | N |
| dbms_pipe.receive_message | Y | N |
| dbms_pipe.remove_pipe | Y | N |
| dbms_pipe.reset_buffer | Y | N* |
| dbms_pipe.send_message | Y | N |
| dbms_pipe.unique_session_name | Y | N* |
| dbms_pipe.unpack_message_bytea | Y | N* |
| dbms_pipe.unpack_message_date | Y | N* |
| dbms_pipe.unpack_message_number | Y | N* |
| dbms_pipe.unpack_message_record | Y | N* |
| dbms_pipe.unpack_message_text | Y | N* |
| dbms_pipe.unpack_message_timestamp | Y | N* |
dbms_sql — dynamic SQL with arbitrary bind types¶
Dynamic bind-variable and column-value handling requires accepting and inspecting an arbitrary caller-supplied type at call time ("any"/anyarray/anyelement), which is a C-level (fmgr) capability — PL/pgSQL's polymorphism is resolved at parse time, not per call, so bind_variable, column_value, execute, execute_and_fetch, and fetch_rows cannot be reproduced. The cursor-bookkeeping functions (open_cursor, is_open, parse, close_cursor, debug_cursor, last_row_count) are convertible in isolation, but without the bind/execute/fetch machinery they can only open and track a cursor that can never be given parameters or read back a result.
| Function | Includes C | Is Converted |
|---|---|---|
| dbms_sql.bind_array [PROCEDURE] | Y | N |
| dbms_sql.bind_variable [PROCEDURE] | Y | N |
| dbms_sql.bind_variable_f | Y | N |
| dbms_sql.close_cursor [PROCEDURE] | Y | N* |
| dbms_sql.column_value [PROCEDURE] | Y | N |
| dbms_sql.column_value_f | Y | N |
| dbms_sql.debug_cursor [PROCEDURE] | Y | N* |
| dbms_sql.define_array [PROCEDURE] | Y | N |
| dbms_sql.define_column [PROCEDURE] | Y | N |
| dbms_sql.desc_rec [TYPE] | N | N/A |
| dbms_sql.describe_columns [PROCEDURE] | Y | N |
| dbms_sql.describe_columns_f | Y | N |
| dbms_sql.execute | Y | N |
| dbms_sql.execute_and_fetch | Y | N |
| dbms_sql.fetch_rows | Y | N |
| dbms_sql.is_open | Y | N* |
| dbms_sql.last_row_count | Y | N* |
| dbms_sql.open_cursor | Y | N* |
| dbms_sql.parse [PROCEDURE] | Y | N* |
plvlex — SQL/PLSQL tokenizing¶
Tokenizing SQL/PLSQL source text requires a real lexer that reproduces PostgreSQL's own quoting rules, dollar-quoting, nested comments, and escape-string handling. Real orafce implements this with a hand-written flex/bison scanner and parser, and correctly re-deriving that state machine in PL/pgSQL is impractical, not merely inconvenient.
| Function | Includes C | Is Converted |
|---|---|---|
| plvlex.tokens | Y | N |
utl_file — raw filesystem I/O¶
Every function does raw operating-system file I/O — fopen/fwrite/fclose/unlink/rename/reading environment variables — and PostgreSQL deliberately does not expose a filesystem API to SQL-callable functions, for security reasons. PL/pgSQL has no built-in that can open, read, write, or delete an arbitrary file on the server.
| Function | Includes C | Is Converted |
|---|---|---|
| utl_file.fclose | Y | N |
| utl_file.fclose_all | Y | N |
| utl_file.fcopy | Y | N |
| utl_file.fflush | Y | N |
| utl_file.fgetattr | Y | N |
| utl_file.file_type [DOMAIN] | N | N/A |
| utl_file.fopen | Y | N |
| utl_file.fremove | Y | N |
| utl_file.frename | Y | N |
| utl_file.get_line | Y | N |
| utl_file.get_nextline | Y | N |
| utl_file.is_open | Y | N |
| utl_file.new_line | Y | N |
| utl_file.put | Y | N |
| utl_file.put_line | Y | N |
| utl_file.putf | Y | N |
| utl_file.tmpdir | Y | N |
That's the full compatibility picture: 247 objects across 15 packages, 162 shipped in the core install (plus the optional VARCHAR2/NVARCHAR2 add-on), and every exclusion tied to a specific, structural C-only capability rather than a gap in effort. If you have existing PL/SQL-derived code and want to know exactly which of these you actually use, see Finding orafce Usage in Your Code.