# 0F001 — invalid_locator_specification

> Source-bounded reference for PostgreSQL SQLSTATE 0F001.
---

# 0F001

## At a glance {#at-a-glance}

SQLSTATE 0F001 is the Invalid Locator Specification member of Class 0F. The locked PostgreSQL definition records the SQL-standard identity, but the resolved PostgreSQL 18.6 core/contrib scan did not find an emitting call. Do not turn the condition name into a claim about PostgreSQL large objects, cursors, FDW handles, or a particular driver API.

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

| Field | Value |
| --- | --- |
| SQLSTATE | `0F001` |
| Condition | `invalid_locator_specification` |
| 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_L_E_INVALID_SPECIFICATION` |
| Aliases | `—` |

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

## Meaning {#meaning}

The member identifies an invalid locator specification when the producing implementation uses the SQLSTATE. The fixed catalogue does not identify the locator representation or the operation that would be invalid in a current PostgreSQL backend. A member code is more specific than 0F000, but still needs its producer and message.

## Messages {#messages}

No fixed PostgreSQL message variant was adopted for this condition because the bounded scan did not resolve a native emitting call.

## Diagnosis {#diagnosis}

Capture the full diagnostic and phase: parse/prepare, execution, descriptor lookup, or a client-side call. Identify the implementation that owns the locator and inspect its fixed documentation or source for accepted locator syntax and lifetime. If PostgreSQL returns another code, keep that code; the 0F001 definition is not a fallback classification.

## Response {#response}

Correct the locator specification or its owning handle according to the producing implementation, then repeat only the failed statement when it is safe and no externally visible work was completed. For a forwarded or client-owned error, repair that boundary rather than changing PostgreSQL transaction policy from the condition name alone.

## Versions {#versions}

The locked catalogue places this condition at least by PostgreSQL 7.4. The release definitions cover the published snapshots listed in the facts block; source-path status is limited to the fixed PostgreSQL 18.6 context cited below.

## Related {#related}

[`0F000`](../0f000/), [`0A000`](../0a000/)

## Sources {#sources}

The fixed [errcodes definition](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/utils/errcodes.txt#L128) establishes the member and macro; the [SQLSTATE appendix](https://www.postgresql.org/docs/18/errcodes-appendix.html) provides the public class table. No resolved 0F001 report path was identified in the locked core/contrib scan. See the structured [evidence record](../data/evidence/0f001.json) for fixed source paths, scan scope, and unresolved runtime boundaries.