From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SQLSTATEs for warnings |
Date: | 2003-07-28 14:23:43 |
Message-ID: | 9132.1059402223@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> In other words, an info, notice, or warning must have a class 00, 01, 02.
I suspect though that the spec is assuming that the SQLSTATE code is the
*only* way for the application to determine whether the message is
success, warning, or error. Since we have other signaling mechanisms
(the severity field, or even more basically the Error/Notice message
type distinction), I'm not convinced we need to be entirely anal about
this division.
AFAICS the alternative to misusing error-class SQLSTATEs as warnings is
that we invent implementation-specific warning codes. Is it really
worth having two codes for what amounts to the same condition?
> However, I noticed several warnings that use codes that are intended for
> errors, for example in portalcmds.c and xact.c.
Several of them are things that probably *ought* to be errors, as you
noted in a later message. I don't recall exactly what other sins I
committed in this area (the whole effort is already becoming a blur ;-)).
We have time to rejigger around the edges though --- I have no objection
to reassigning codes during beta. Once we release it will get harder.
A possibly related sin in the same category is that I think that the
class-40 SQLSTATEs are intended to imply that the server has forcibly
aborted your whole transaction --- not just the current statement, which
is what I think the spec envisions for all the other error classes.
We do not currently make that distinction, but sooner or later we will.
Perhaps we should avoid the class-40 codes and make our own
implementation-dependent codes for deadlock detection and so forth.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-07-28 14:26:52 | Re: Passing server_encoding to the client is not future-proof |
Previous Message | Peter Eisentraut | 2003-07-28 14:12:16 | Error code mixup? |