On Tue, Aug 4, 2009 at 5:23 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers