Sam Mason <s...@samason.me.uk> wrote: > It just looks like a fixed set of numbers for a fixed set of > conditions, can't find any canonical definition about what it's > really for though. Sorry, I'm familiar with the SQLSTATE's role in the spec, I just wasn't sure how specific they got in their table of standard values regarding particular constraints. From the spec:
"The character string value returned in an SQLSTATE parameter comprises a 2-character class value followed by a 3-character subclass value, each with an implementation-defined character set that has a one-octet character encoding form and is restricted to <digit>s and <simple Latin upper case letter>s. Table 32, *SQLSTATE class and subclass values*, specifies the class value for each condition and the subclass value or values for each class value." and: "If a subclass value is not specified for a condition, then either subclass '000' or an implementation-defined subclass is returned." >From the table, the 23xxx series is for integrity constraint violations, but they appear not to have gotten too specific about breaking that down; thereby leaving it as an implementation choice: integrity constraint violation 23 (no subclass) 000 restrict violation 001 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. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
