Re: the case for machine-readable error fields

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> 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.

Also, you completely dodged the question of defining what the fields
really mean, which would be 100% essential to doing anything automatic
with the results. If "errtable" sometimes means a table that doesn't
exist, and sometimes means a table that exists but doesn't contain an
expected column, or sometimes a table that exists but doesn't contain
an expected value, or sometimes a table that exists and contains a
value that shouldn't be there, etc etc, then actually doing anything
interesting with the information is going to be a matter of guess and
hope rather than something that's reliably automatable. As a single
example, in a foreign-key error message, is "errtable" going to be
the referencing table or the referenced table? And how would an
application writer predict that? If you don't have a clear design
rule that tells the answer, there is absolutely no chance of achieving
any consistency among the hundreds or thousands of ereports that will
have to be consistent in order for this feature to be worth anything.
Let alone whatever random effects an errcontext callback would produce;
I don't think you've thought through that bit at all.

regards, tom lane