Re: SQLSTATEs for warnings

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-08-01 13:45:32
Message-ID: 7526.1059745532@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:
> Tom Lane writes:
>> 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.

> The severity field is useless, because it contains localized text that
> cannot be evaluated by a program.

Fair point.

> Also, neither the severity field nor
> the error/notice message distinction is necessarily available in
> interfaces that work at a layer above libpq (e.g., embedded SQL).

An interface library would have to really go out of its way to make
errors and notices look alike, at least if it's built atop libpq.
I think this argument is pretty weak. But you're right about severity.

>> AFAICS the alternative to misusing error-class SQLSTATEs as warnings is
>> that we invent implementation-specific warning codes.

> I don't see that as being allowed.

Hm? Surely we can invent implementation-defined warning codes in the
ranges 015xx-019xx and 01Ixx-01Zxx. If not, what other alternative
do you propose?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Treat 2003-08-01 14:00:08 Fwd: Re: [ANNOUNCE] PostgreSQL Weekly News - July 30th 2003
Previous Message Tom Lane 2003-08-01 13:31:26 Re: Another nasty pg_dump problem