Re: the case for machine-readable error fields

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Right now, I do this like this:

> if ($err =~ /name_of_first_foreign_key/) {
> $r->error_exit('First error message.')
> }
> elsif ($err =~ /name_of_second_foreign_key/) {
> ...

> I've always found that a bit icky because it relies (for example) on
> their not being two constraint names such that the first is a prefix
> of the second, and on there not being any other data in the error
> string which can be confused with the constraint name.

As for the prefix bit, doesn't perl have a "word boundary" regexp
constraint?

However, I wonder whether we could turn this around. Instead of an
open-ended project to add an ill-defined collection of fields to an
ill-defined collection of error cases, maybe we could identify a
very short list of cases where it's known to be useful to pull a
specific bit of information out of a specific error message. And
then implement just those.

A minimum requirement for such a thing, in my opinion, is that *every*
occurrence of one of the targeted SQLSTATE codes should be able to
produce the same auxiliary fields with the same meanings. If you can't
define it that way, then you haven't actually made things better than
looking at the message text.

The bottom line behind my complaining is that this isn't going to be
helpful unless it's very clearly defined which error reports produce
what auxiliary fields. The impression I got from Alvaro's comments
was that he wanted to decorate everything in sight with anything he
could think of, which perhaps is not what he intended.

regards, tom lane