Re: the case for machine-readable error fields

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

Frankly, I don't believe it. I've seen possibly one or two requests
for such things. That's not enough interest to justify the kind of
work and code-size investment you're talking about.

If there are situations where this info is missing from the
human-readable message, then sure, let's look into fixing that.
But the use-case for automatic interpretation of the message
is just a whole lot smaller than would justify the work.
To take just one point, I rather doubt that SQLSTATE codes are really
sufficiently fine-grained to let applications automatically determine
what to do without looking at the message text.

regards, tom lane