Todo item: Include the symbolic SQLSTATE name in verbose error reports
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t139198psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 09:05 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t139198_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t139198_1 && git checkout t139198_1Patchset v1 (message #1) is on t139198_1
Hi,
Attached is a patch implementing an old feature request on the wiki's Todo:
"Include the symbolic SQLSTATE name in verbose error reports"
The output should only be different in verbose mode, i.e. if you:
\set VERBOSITY verbose
The old output in verbose mode would look like:
# SELECT * FROM nonexistent_table;
ERROR: 42P01: relation "nonexistent_table" does not exist
LINE 1: SELECT * FROM nonexistent_table;
LOCATION: parserOpenTable, parse_relation.c:1461
The new output looks like:
# select * FROM nonexistent;
ERROR: 42P01 (ERRCODE_UNDEFINED_TABLE): relation "nonexistent" does not
exist
LINE 1: select * FROM nonexistent;
^
LOCATION: parserOpenTable, parse_relation.c:1461
so that we tell the user clearly what "42P01" means, in this example.
Cheers,
Josh
Josh Kupershmidt <schmiddy@gmail.com> writes:
Attached is a patch implementing an old feature request on the wiki's Todo:
"Include the symbolic SQLSTATE name in verbose error reports"
I kind of doubt that this is actually useful (which presumably is
the reason the TODO item has languished uncompleted for so long).
The first problem is that the SQL spec's list of error codes isn't
very granular, so that there are many cases where different errors
with different messages have been mapped to the same SQLSTATE.
You are way better off to read the message text than to believe
that the SQLSTATE is a useful summary.
The second problem is that the proposed implementation relies on
libpq to know the server's list of SQLSTATEs, with obvious risks
for cross-version skew.
I also wonder if this wouldn't break some applications that are
expecting specific output from psql, or for that matter from
anything else relying on libpq's error message formatting.
No doubt such apps could be fixed, but the cost/benefit ratio
just doesn't seem all that attractive.
regards, tom lane