"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Josh Berkus <josh@agliodbs.com> wrote:
>> I'm less concerned about the standard here and more concerned
>> about what helps our users. Having column names for an FK error
>> is *extremely* useful for troubleshooting, particularly if the
>> database has been upgraded from the 7.4 days and has non-useful FK
>> names like "$3".
> If it gives a FK constraint name, isn't there a way to get from that
> to the columns used by the constraint? If we want to support
> something non-standard, we can always tell them to look at the text
> of the error detail, right?
Yes. This is entirely *not* about friendliness to human users; they're
going to read the existing primary/detail/hint fields, and probably
aren't even going to see these new error fields by default. What the
new fields are meant for is allowing client programs to do something
useful without parsing the text of the human-oriented fields ... for
instance, identify which FK constraint got violated. Somebody who's
intending to use this functionality would presumably take care to give
his constraints names that were helpful for his purposes. Moreover,
if he's hoping to use that client code against more than one database,
what he's going to want is SQL-standard functionality, not more nor less.
As for the "my constraints have names like $3" argument, maybe an ALTER
CONSTRAINT RENAME command would be the most helpful answer.
regards, tom lane
