Re: the case for machine-readable error fields

Tom Lane wrote:
> 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.

Huh, yeah, certainly there are cases where the errtable() call is going
to be directly in the ereport() call instead of errcontext, but in some
other cases (for example when reporting problems in functions) we're
going to need errcontext.

> 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.

Hmm, well, I skipped the rationale because it has been requested before.
For example, we need to give constraint names so that applications can
tell which unique key is being violated. We need table names on which
they are being violated. We need column names for datatype mismatches,
and so on. We frequently see people parsing the error message to
extract those, but that is known to be fragile, cumbersome and error
prone.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.