Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wRaVF-002UeG-0k for pgsql-hackers@arkaria.postgresql.org; Mon, 25 May 2026 18:58:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wRaVC-001riF-2r for pgsql-hackers@arkaria.postgresql.org; Mon, 25 May 2026 18:58:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wRaVC-001ri6-1w for pgsql-hackers@lists.postgresql.org; Mon, 25 May 2026 18:58:15 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wRaVB-00000001OhX-2OeV for pgsql-hackers@postgresql.org; Mon, 25 May 2026 18:58:15 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 64PIwBeF136110; Mon, 25 May 2026 14:58:11 -0400 From: Tom Lane To: Josh Kupershmidt cc: pgsql-hackers Subject: Re: Todo item: Include the symbolic SQLSTATE name in verbose error reports In-reply-to: References: Comments: In-reply-to Josh Kupershmidt message dated "Wed, 01 Apr 2026 09:44:15 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <136108.1779735491.1@sss.pgh.pa.us> Date: Mon, 25 May 2026 14:58:11 -0400 Message-ID: <136109.1779735491@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Josh Kupershmidt 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