Re: the case for machine-readable error fields - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: the case for machine-readable error fields
Date
Msg-id 162867790908051157of645c38mba806924d7b483a9@mail.gmail.com
Whole thread Raw
In response to Re: the case for machine-readable error fields  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: the case for machine-readable error fields  (Sam Mason <sam@samason.me.uk>)
List pgsql-hackers
2009/8/5 Tom Lane <tgl@sss.pgh.pa.us>:
> Sam Mason <sam@samason.me.uk> writes:
>> On Wed, Aug 05, 2009 at 12:41:30PM -0500, Kevin Grittner wrote:
>>> Anyway, it was a bad suggestion that we provide a way to specify a
>>> SQLSTATE to use for a constraint failure.  I do think that some field
>>> which could be used for that purpose would be good.  Preferably
>>> something which could be specified in the declaration of the
>>> constraint.
>
>> I still stand by my assertion that the constraint name is sufficient for
>> the original purpose.
>
> Yeah.  Changing the SQLSTATE for a given error seems much more likely
> to break things than to be helpful.  It does make sense to be able to
> extract the constraint name for a constraint-related error without
> having to make unsafe assumptions about the spelling of the
> human-readable error message, though.
>
> Peter pointed out upthread that the SQL standard already calls out some
> things that should be available in this way --- has anyone studied that
> yet?

yes - it's part of GET DIAGNOSTICS statement

http://savage.net.au/SQL/sql-2003-2.bnf.html#condition%20information%20item%20name

regards
Pavel Stehule
>
>                        regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: the case for machine-readable error fields
Next
From: Josh Berkus
Date:
Subject: Re: GRANT ON ALL IN schema