0A000

At a glance

SQLSTATE 0A000 is feature_not_supported in Class 0A. 0A000 means a recognized feature or option is unsupported in the selected context. The selected hash-index path requests id ASC, reports access method "hash" does not support ASC/DESC options, then accepts the same index without ordering. This is an access-method capability decision, not 42501 privilege denial or 42601 parser failure.

Meaning

The selected ComputeIndexAttrs path rejects ordering options for the hash access method, even though the index request itself is syntactically valid. The useful distinction is capability versus syntax: id ASC reaches the access-method check and produces the exact ERROR, while the same key without ordering is accepted.

This is a property of the chosen access method, not of the column type or the table’s contents. The command parser has already accepted the index definition; ComputeIndexAttrs then checks whether the access method can honor the requested ordering. A btree index may support the ordering option, while a hash index in this path does not. Other 0A000 producers can reject different features, so the complete primary message and command context remain essential.

Diagnosis

Read the complete primary message and identify the access method, option, command context, and server version. The failed statement leaves the autocommit session IDLE; the repaired index is valid according to pg_index.indisvalid. Other 0A000 paths can have different object and recovery behavior.

Check the object names before interpreting the result. In the case SQL, the first table and indexes are unqualified and therefore use search_path; feature_schema.hash_index in the final regclass lookup is a placeholder for the actual schema-qualified index. Confirm that those names refer to the object just created, then compare the access method and options with its documented capabilities. A privilege error (42501) or parse error (42601) calls for a different branch of diagnosis.

Response

Remove or replace only the unsupported option, or choose an access method whose contract supports it. Verify the resulting object and its semantics; do not treat every 0A000 as an upgrade request or silently discard the requested feature.

The selected autocommit ERROR can be followed by a corrected CREATE INDEX in the same session. In an explicit transaction, recover the local transaction with ROLLBACK or an intentional savepoint before issuing unrelated DDL; after recovery, recreate the index with an access method and options whose semantics meet the original requirement. Do not assume a successful replacement preserves ordering guarantees that the rejected definition requested.

Observed diagnostics

The fixed index-command branch emits ERROR with primary access method "%s" does not support ASC/DESC options; the access-method name is dynamic. This is the selected hash-index variant. Other unsupported features can use different 0A000 messages and recovery boundaries.

In the selected branch the dynamic value is hash, and the server emits no fixed DETAIL or HINT. The run observed the failed command in autocommit with session status IDLE; that status is not a general property of every 0A000 producer or of the same command inside an explicit transaction.

Representative case

The SQL block creates a table, tries the unsupported ordered hash index, creates the repaired index, and verifies pg_index.indisvalid.

feature_schema.hash_index in the final regclass lookup is a placeholder for the schema-qualified relation actually created by the first three statements. Those statements use unqualified feature_table and hash_index, so they depend on the current search_path; when running the block manually, either set that path intentionally or qualify/create the table and index in the schema named by the verification query.

CREATE TABLE feature_table (id integer NOT NULL, payload text);
CREATE INDEX hash_index ON feature_table USING hash (id ASC);
CREATE INDEX hash_index ON feature_table USING hash (id);
SELECT indisvalid FROM pg_index WHERE indexrelid = 'feature_schema.hash_index'::regclass;

The selected 18.6 run reports SQLSTATE 0A000, primary access method "hash" does not support ASC/DESC options, 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 0A000 case JSON and authored evidence. The runner manifest is verify/cases/0A000/cases.json; the page SQL is checked against its shared registry before publication.

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

• 0LP01 — invalid_grant_operation
• 25006 — related condition

Sources

• src.indexcmds-asc-desc.18.6 — src/backend/commands/indexcmds.c at REL_18_6 commit 724edf9bde9d356724ad384a2e196edc3c9f80f7; fixed blob SHA-256 0bdae365f207ab82865806c5983cac94c5c062e7a61ab7c883ccb7e2015fad36 (source).
• src.indexcmds-asc-desc.10.23 — src/backend/commands/indexcmds.c at REL_10_23 commit 02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4; fixed blob SHA-256 97766ba385fea1ba642e5b077fd5ce7cbb9f9faff177bcece0de2fc3e2904b23 (source).
• 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.