Re: the case for machine-readable error fields

On Tue, Aug 4, 2009 at 11:28 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)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