# 3F000 — invalid_schema_name > PostgreSQL SQLSTATE 3F000: invalid_schema_name, source-backed diagnosis and recovery guidance. --- # 3F000 ## At a glance {#at-a-glance} SQLSTATE `3F000` is **invalid_schema_name** in Class `3F`. `3F000` means a schema name cannot be resolved in an established session. The selected qualified-table path receives `schema "" does not exist`, while fixed namespace and schema-command paths cover resolution during object creation and other SQL commands; it is not simply a `search_path` hint. | Field | Value | | --- | --- | | SQLSTATE | `3F000` | | Condition | `invalid_schema_name` | | Status | `active` | | Known present by | `7.4` | | Locked snapshots | `9.0.23, 9.1.24, 9.2.24, 9.3.25, 9.4.26, 9.5.25, 9.6.24, 10.23, 11.22, 12.22, 13.23, 14.24, 15.19, 16.15, 17.11, 18.6, 19beta3` | | Macros | `ERRCODE_INVALID_SCHEMA_NAME, ERRCODE_UNDEFINED_SCHEMA` | | Aliases | `ERRCODE_UNDEFINED_SCHEMA` | ## Meaning {#meaning} The namespace lookup raises this condition when a schema name itself cannot be resolved. A qualified reference to an absent schema uses `schema "%s" does not exist`; an unqualified CREATE path with no usable creation namespace uses `no schema has been selected to create in`. Both are schema-resolution branches. An ordinary unqualified relation lookup that finds no relation is `42P01`, even when the reason is an unsuitable `search_path`; a privilege denial follows `42501`. The first question is whether the failing name is a schema or a relation. A qualified reference such as `missing_schema.repaired_table` asks the namespace code for that exact schema and can produce `3F000`. A CREATE with no explicit schema can produce `3F000` when no schema is selected for creation. By contrast, `SELECT * FROM missing_table` is an unqualified relation lookup and normally produces `42P01`; `search_path` helps explain which relations are searched but does not change that SQLSTATE into `3F000`. A role that lacks the required privilege follows `42501`. These are different repairs even when the application reports them as “schema not found”. ## Diagnosis {#diagnosis} Distinguish an explicitly missing schema, a CREATE with no selected creation schema, an unqualified relation lookup, and 42501 privilege denial. The selected autocommit session is `IDLE` after the ERROR; the owner creates the intended schema and table, inserts one row, and verifies it under the explicit namespace. Check the same role and database used by the failing command. Inspect the failing identifier with the same role and database, for example by checking `current_schemas(true)` and whether the intended schema resolves in the catalog. Then verify the command's qualification: the selected case deliberately uses a missing qualified schema. If the statement is CREATE without a schema, inspect whether `search_path` has any usable creation target; if it is an unqualified relation read, classify a missing relation as `42P01` rather than `3F000`. In an explicit transaction, the selected `ERROR` can leave the transaction in `INERROR`; the autocommit `IDLE` observation is not a universal recovery result. ## Response {#response} Use the migration or owner-controlled `CREATE SCHEMA`, set or qualify the intended namespace, and verify the object under the same role. For `no schema has been selected to create in`, choose an allowed creation schema or qualify the CREATE statement. For an unqualified missing relation, repair the relation name or its intended `search_path` and expect `42P01` until the relation resolves. Keep schema creation separate from adding unrelated entries to `search_path`; if the name was intentionally removed, repair the migration or target rather than retrying unchanged. After creating or exposing the schema, rerun the exact qualified statement and verify the resulting object with the same role. If the failed statement is inside an explicit transaction, roll back or return to a planned savepoint before issuing unrelated DDL. Do not grant broad schema privileges as a substitute for checking whether the application used the right database or identifier. ## Observed diagnostics {#messages} The fixed namespace paths emit `ERROR` with primary `schema "%s" does not exist` for an explicitly missing schema and `no schema has been selected to create in` when an unqualified CREATE has no active creation namespace. The selected qualified-table case has no fixed DETAIL or HINT. An unqualified relation miss is the separate `42P01` `relation "%s" does not exist` path, while a role's lack of privilege is `42501`. The selected dynamic name is `c3f000_invalid_schema_name_missing`, and the error occurred after session establishment with no fixed DETAIL or HINT. This is distinct from the source-defined schema-command paths and from a client startup failure. ## Representative case {#case} The SQL block qualifies a missing schema, creates the schema and table, inserts one row, verifies it, and drops the disposable schema. ```sql CREATE TABLE missing_schema.repaired_table (id integer); CREATE SCHEMA missing_schema; CREATE TABLE missing_schema.repaired_table (id integer); INSERT INTO missing_schema.repaired_table VALUES (1); SELECT count(*) FROM missing_schema.repaired_table; DROP SCHEMA missing_schema CASCADE; ``` The selected 18.6 run reports SQLSTATE `3F000`, primary `schema "c3f000_invalid_schema_name_missing" does not exist`, and the asserted recovery state is `IDLE` before the final probe/repair. Every assertion and cleanup passed on 18.6 and 10.21. The downloadable case and evidence projections are [`3F000 case JSON`](../data/cases/3f000.json) and [`authored evidence`](../data/evidence/3f000.json). The runner manifest is `verify/cases/3F000/cases.json`; the page SQL is checked against its shared registry before publication. ## Versions {#versions} The generated facts table records the locked catalogue snapshots and earliest observed definition. The selected natural runtime scope is PostgreSQL 18.6 and 10.21; this does not infer behavior for every intermediate release. ## Related {#related} - [`3D000` — invalid_catalog_name](../3d000/) - [`42501` — related condition](../42501/) ## Sources {#sources} - `src.namespace-missing-schema.18.6` — `src/backend/catalog/namespace.c` at `REL_18_6` commit `724edf9bde9d356724ad384a2e196edc3c9f80f7`; fixed blob SHA-256 `8c9e6a99e84fa2cec8a9b1de2ecbe3966a13f4ad68c6ccfbfb8134a754d73e56` ([source](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/catalog/namespace.c#L3545-L3547)). - `src.namespace-missing-schema.10.23` — `src/backend/catalog/namespace.c` at `REL_10_23` commit `02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4`; fixed blob SHA-256 `74833354740d0e5679507d07b3c6e41aea01c2cb30adcd1e238bed3ebf96ddc6` ([source](https://github.com/postgres/postgres/blob/02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4/src/backend/catalog/namespace.c#L3022-L3024)). - `src.namespace-creation-no-schema.10.23` — `src/backend/catalog/namespace.c` at `REL_10_23` commit `02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4`; fixed blob SHA-256 `74833354740d0e5679507d07b3c6e41aea01c2cb30adcd1e238bed3ebf96ddc6` ([source](https://github.com/postgres/postgres/blob/02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4/src/backend/catalog/namespace.c#L2967-L3004)). - `src.parse-relation-undefined-table.10.23` — `src/backend/parser/parse_relation.c` at `REL_10_23` commit `02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4`; fixed blob SHA-256 `a34f40fc93fa5df0015fe5af5ee7761ccba2d16a791cda69ae07848ed27616b5` ([source](https://github.com/postgres/postgres/blob/02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4/src/backend/parser/parse_relation.c#L1147-L1184)). - `src.calls.REL_18_6` / `src.calls.REL_10_23` — fixed local call scans, SHA-256 `9ee8a0e81d8f0825c5c1ae45583439859a26e602bdd4ce2f2a62aa278867ccbf` / `00d16d3eb01b71ccf1b245c8f3102f9d0ec9f36fb02777b8dd1b99fcb263040c`; these scans preserve the resolved call context used by the claims.