To: "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Cc: "Neil Conway" <neilc@samurai.com>,
	"PostgreSQL Hackers" <pgsql-hackers@postgresql.org>
Subject: Re: Upgrading the backend's error-message infrastructure 
In-reply-to: <0d9901c2e9d4$9a3ad280$6500a8c0@fhp.internal> 
References: <9168.1047588660@sss.pgh.pa.us>
	<0cfd01c2e9cf$c16ea070$6500a8c0@fhp.internal>
	<1047609869.357.1856.camel@tokyo>
	<0d9901c2e9d4$9a3ad280$6500a8c0@fhp.internal>
Comments: In-reply-to "Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
	message dated "Fri, 14 Mar 2003 10:51:24 +0800"
Date: Thu, 13 Mar 2003 22:47:30 -0500
Message-ID: <14866.1047613650@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Would it be possible to do a command line app?
> 
> bash$ pg_error 1200D
> Severity: ERROR
> Message: Division by zero
> Detail:
> Hint: Modify statement to prevent zeros appearing in denominators.

You're assuming that there's a one-to-one mapping of error codes to
messages, which is not likely to be the case --- for example, all the
"can't happen" errors will probably get lumped together under a single
"internal error" error code.  You could provide a lookup of the
spec-defined meaning of each error code, maybe.

>> Is there any benefit to having this over just including an index of
>> error codes in the documentation?

> It's quick and easy, especially when there's thousands of error codes.

But there aren't.  I count about 130 SQLSTATEs defined by the spec.
Undoubtedly we'll make more for Postgres-specific errors, but not
hundreds more.  There's just not value to applications in distinguishing
errors at such a fine grain.

			regards, tom lane