| 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: | Whole Thread | Raw Message | 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 |