On Tue, Aug 4, 2009 at 5:23 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.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?
Yep, and it is in fact useful for these kinds of situations. At least
for me (and I obviously don't have to contend with translation issues
as Alvaro does, since I have the advantage of speaking the
untranslated language) the ickiness of the current situation is
manageable. It's not ideal, but it is manageable.
> 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.
Perhaps not. :-)
Maybe a specific list of the places where he'd like to add things
would be helpful.
...Robert
