Thread

1. Todo item: Include the symbolic SQLSTATE name in verbose error reports

   Josh Kupershmidt <schmiddy@gmail.com> — 2026-04-01T13:44:15Z

   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
   

2. Re: Todo item: Include the symbolic SQLSTATE name in verbose error reports

   Tom Lane <tgl@sss.pgh.pa.us> — 2026-05-25T18:58:11Z

   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