Re: the case for machine-readable error fields

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> First we need several new error message fields: table name, function
> name, constraint name, and so on.

It would also help to have clear definitions of what these *mean*, which
is entirely unclear from your comments --- in particular, the reference
to errcontext callbacks confuses the heck out of me. I would have
thought that these would be used for the referenced object name in cases
like "table not found", and surely using an errcontext callback for that
would be the hardest possible way to implement it.

> ... would be to give each new field its own start letter (see
> http://www.postgresql.org/docs/8.4/static/protocol-error-fields.html);
> say "T" for table, "f" for function (F is taken), "c" for constraint (C
> is taken), and so on. Another possibility would be to use a single
> letter, say N, and add a subtype to it; so table name would be "NT"
> followed by the table name, NF for functions, etc.

Without a pretty concrete list of what the additions are going to be,
it's difficult to make any reasoned choices there.

Lastly, I'm not as sure as you are that the case for these is well made.
In exactly what cases would client code be able to do something useful
with them? Your proposal involves a pretty huge amount of work if we
are to carry it out thoroughly, and I'm 100% not convinced that there's
a proportional benefit.

regards, tom lane