On Tue, Aug 4, 2009 at 11:28 PM, Tom Lane<t...@sss.pgh.pa.us> wrote: > > Huh? What he was talking about is providing additional error fields, > which would presumably be made available via PQresultErrorField in > libpq, or its kin in other interfaces, and would be totally invisible to > any client that didn't ask for them. I can't imagine any value-add > from introducing XML into the problem.
Well it could add a single field which contained a structured description of the error. That would solve the problem you described for things like foreign key references which require two sets of table and column lists and assigning meanings to them both -- essentially because a single list of fields isn't really rich enough to describe all possible errors. But I wonder if it's really that hard to parse the text errors. We have a pretty formulaic construction for our error messages. And we quote things pretty aggressively and prefixing name with the object type pretty consistently. Fixing any cases where we don't follow the rules and fixing the rules in cases where it's hard to parse seems like at least as good a solution. So an alternate proposal is to add a field in the error message which contains the untranslated string. That would let applications always look at the untranslated string for parsing and always use the translated string for user displays. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers