From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Ian Pilcher <arequipeno(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Range for user-defined SQLSTATE codes |
Date: | 2013-01-26 16:52:18 |
Message-ID: | 20185.1359219138@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> Ian Pilcher <arequipeno(at)gmail(dot)com> wrote:
>> Is there anything like a standard range -- formal or otherwise -- for
>> such codes? A best practice? A general consensus? A half-painted
>> bike shed?
> There is this in the SQL standard. According to that, SQLSTATE
> values with 0-4 or A-H in both the first and third positions are
> reserved for values defined by standards. All others are available
> for "implementation-specified" exception conditions. As far as I
> know, the PostgreSQL community has claimed SQLSTATE values with P0
> or XX in the start of a SQLSTATE or P in the third character. To
> allow for future expansion by the PostgreSQL community it might be
> wise to stay away from any SQLSTATE starting with P for your
> application use.
In addition to what the spec says, it's worth looking into
src/backend/utils/errcodes.txt, where you'll note that we have borrowed
some codes beginning with '5' from DB2, and also stated that codes
beginning with 'Y' are reserved for client-side code such as ecpg.
So I'd stay away from 5, P, X, and Y as first characters of private
SQLSTATEs (or third characters of private codes within a spec-defined
class, if that's what you want). Other than that, go nuts.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Pilcher | 2013-01-26 21:13:29 | Cast double precision to integer & check for overflow |
Previous Message | Kevin Grittner | 2013-01-26 15:40:48 | Re: Range for user-defined SQLSTATE codes |