# 0A000 — feature_not_supported

> PostgreSQL SQLSTATE 0A000: feature_not_supported, source-backed diagnosis and recovery guidance.
---

# 0A000

## At a glance {#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.

<!-- BEGIN SQLSTATE FACTS: generated by scripts/generate.py; do not edit -->

| Field | Value |
| --- | --- |
| SQLSTATE | `0A000` |
| Condition | `feature_not_supported` |
| 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_FEATURE_NOT_SUPPORTED` |
| Aliases | `—` |

<!-- source facts: data/errcodes/0A000.json -->
<!-- END SQLSTATE FACTS -->

## Meaning {#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 {#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 {#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 {#messages}

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 {#case}

<!-- BEGIN SQLSTATE SNIPPET: hash_index_feature -->

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.

```sql
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;
```

<!-- END SQLSTATE SNIPPET -->

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`](../data/cases/0a000.json) and [`authored evidence`](../data/evidence/0a000.json). The runner manifest is `verify/cases/0A000/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}

- [`0LP01` — invalid_grant_operation](../0lp01/)
- [`25006` — related condition](../25006/)

## Sources {#sources}

- `src.indexcmds-asc-desc.18.6` — `src/backend/commands/indexcmds.c` at `REL_18_6` commit `724edf9bde9d356724ad384a2e196edc3c9f80f7`; fixed blob SHA-256 `0bdae365f207ab82865806c5983cac94c5c062e7a61ab7c883ccb7e2015fad36` ([source](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/commands/indexcmds.c#L2244-L2247)).
- `src.indexcmds-asc-desc.10.23` — `src/backend/commands/indexcmds.c` at `REL_10_23` commit `02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4`; fixed blob SHA-256 `97766ba385fea1ba642e5b077fd5ce7cbb9f9faff177bcece0de2fc3e2904b23` ([source](https://github.com/postgres/postgres/blob/02991e79f8f58bc208f05dcc8af0c62dbe0a6ea4/src/backend/commands/indexcmds.c#L1403-L1406)).
- `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.