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/
