Re: Upgrading the backend's error-message infrastructure

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "Neil Conway" <neilc(at)samurai(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Upgrading the backend's error-message infrastructure
Date: 2003-03-14 03:47:30
Message-ID: 14866.1047613650@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-interfaces

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Taral 2003-03-14 05:04:01 Re: No merge sort?
Previous Message Tom Lane 2003-03-14 03:30:27 Re: No merge sort?

Browse pgsql-interfaces by date

  From Date Subject
Next Message Dave Page 2003-03-14 08:47:03 Re: Roadmap for FE/BE protocol redesign
Previous Message Larry Rosenman 2003-03-14 03:01:01 Re: Upgrading the backend's error-message infrastructure