2200D — invalid_escape_octet
2200D
At a glance
The catalogue condition covers an invalid escape octet. The fixed scan did not resolve a PostgreSQL 18.6 emitting function for this entry, so the condition is useful as a classification boundary rather than proof of one native parser call.
| Field | Value |
|---|---|
| SQLSTATE | 2200D |
| Condition | invalid_escape_octet |
| 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_ESCAPE_OCTET |
| Aliases | — |
Meaning
This condition classifies an escape octet that the consuming parser cannot accept; its owner must be identified from the real message.
Diagnosis
Start with the complete server message and the input field named by the surrounding operation. Check byte encoding and the layer that interpreted the escape (SQL literal, regular-expression or extension parser). Do not replace this code with 2200C solely because both names mention escapes; the server’s actual SQLSTATE and message decide the path. No fixed native emitter was confirmed in this scan.
Response
Preserve the complete diagnostic, identify the parser or wrapper that supplied the invalid octet, and correct the input or encoding at that boundary before retrying.
Versions
The locked catalogue records this condition from 7.4; fixed source coverage is PostgreSQL 18.6.
Related
Sources
The fixed definition is confirmed; this bounded scan did not resolve a native emitting function to cite. The structured evidence record retains the definition, message, and scope boundaries. The definition is fixed in errcodes.txt, but implementation ownership and exact message variants remain unknown here. Locate the wrapper or extension named by the real message before changing data or retrying.