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
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? |
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 |