Why It Refuses to Install Over Real orafce

Both install modes run the same preflight check before creating anything, and both fail the same way if it doesn't pass. This is deliberate, not a limitation to work around — here's exactly what it checks and why.

The two checks

1. Is real orafce already installed in this database?

IF EXISTS (SELECT 1 FROM pg_extension WHERE extname = 'orafce') THEN
    RAISE EXCEPTION 'orafce_no_c: the real "orafce" extension is already
    installed in this database. orafce_no_c is a drop-in, C-free
    replacement and cannot coexist with it -- both packages claim the
    exact same schema names (oracle, plvstr, plvdate, ...). Run "DROP
    EXTENSION orafce;" first if you intend to switch to orafce_no_c
    (after confirming nothing else in this database depends on it).'
        USING ERRCODE = 'object_not_in_prerequisite_state';
END IF;

orafce_no_c is meant as a replacement, not an addition — it uses the exact same 10 schema names (oracle, plvstr, plvdate, and so on) as real orafce, since that's what makes it a drop-in swap for code that already calls oracle.instr(...), plvstr.rvrs(...), and so on. Two extensions can't both own the same schema, so installing over a live real-orafce install would either fail outright or silently clobber something. orafce_no_c chooses to fail loudly, immediately, before touching anything.

2. Does any of the 10 target schemas already exist, for any other reason?

SELECT string_agg(quote_ident(n), ', ' ORDER BY n)
  FROM unnest(ARRAY['dbms_assert','dbms_output','dbms_random',
                     'dbms_utility','oracle','plunit','plvchr',
                     'plvdate','plvstr','plvsubst']) AS n
  WHERE EXISTS (SELECT 1 FROM pg_namespace WHERE nspname = n);
-- if any found:
RAISE EXCEPTION 'orafce_no_c: the following schema(s) already exist and
orafce_no_c will not overwrite or drop them: %. Rename or drop the
conflicting schema(s) yourself first, or install orafce_no_c into a
different database.', v_conflicting_schemas
    USING ERRCODE = 'duplicate_schema';

Maybe you have your own schema named oracle for an unrelated reason, or a previous partial install left something behind. Either way, orafce_no_c never drops or overwrites a schema it doesn't already own — it only fails loudly and lets you resolve the conflict yourself.

What "fails cleanly" means

Both checks run inside a single preflight block, before any schema or object is created. If either check fails, the whole install aborts with nothing partially created — there's no state to clean up, and no risk of a half-installed extension. This applies to a fresh install only; a future version upgrade (via ALTER EXTENSION orafce_no_c UPDATE) doesn't repeat these checks, since the schemas are expected to already exist at that point.

If you're mid-migration

If you still have real orafce installed and want to test orafce_no_c side by side first, don't install orafce_no_c into the same database at all — this is exactly the scenario the audit tool and the schema-rename trick used throughout this project's own testing are for: install orafce_no_c under a renamed schema (or in a separate database entirely) to compare behavior before committing to a real cutover. Once you're ready to switch for real, DROP EXTENSION orafce; first, then install orafce_no_c as normal.

Continue to Uninstalling.