On Tue, Aug 04, 2009 at 01:12:10PM -0400, Alvaro Herrera wrote: > First we need several new error message fields: table name, function > name, constraint name, and so on. One possible way to go about this > would be to give each new field its own start letter (see > http://www.postgresql.org/docs/8.4/static/protocol-error-fields.html); > say "T" for table, "f" for function (F is taken), "c" for constraint (C > is taken), and so on. Another possibility would be to use a single > letter, say N, and add a subtype to it; so table name would be "NT" > followed by the table name, NF for functions, etc.
As pointed out downstream this seems somewhat open-ended and arbitrary; I would start with just making the constraint name easy to get to--I hope this doesn't happen already as I can't see anything obvious. My rational is that everything (short of syntax errors and strange things in the procedural languages) is already associated with a constraint. Syntax errors seem awkward to get standardized reporting for, the syntax keeps changing meaning that reporting anything more than what we do now doesn't seem practically useful. The calling code isn't going to be able to generate different SQL depending on error messages we give back, a human is needed there and can still interpret the text as well as we've always done. Constraints failing are a useful thing that calling code can do useful things with and it makes sense to give this back. These would seem to capture everything you mentioned elsewhere except UNIQUE indexes that weren't created as a constraint. Maybe this could be fixed by turning them into a constraint? as they seem like one to me. What are people doing with parsing error messages for "column names for datatype mismatches"? I can't imagine any of my code being able to do anything sensible in such a case. If it's things like people giving dates to the database in an incorrect format then that's what they get for not doing input validation isn't it? -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
