Re: the case for machine-readable error fields

Tom Lane wrote:

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

The message text is unparsable, because sometimes it is translated. If
the application wants to do something particular upon receiving a
particular error message, it has two choices: either it parses the
string, in which case it better not be translated, or it passes it to
the user untouched, in which cases it better be translated. There's no
way the application can try to do both things at once.

For example, say an application needs to capture a certain class of
errors to take automatic action, but pass others to the user untouched
for display (unexpected condition). This is not all that uncommon.
However, there's no way to do this at present. What I've done is check
the SQLSTATE, but then I can't get the affected table name. (Normally
the application knows which is the affected table, but this is not
always the case.)

I don't know about finegrainedness of SQLSTATEs but I haven't had
problems with that. ERRCODE_UNIQUE_VIOLATION appears twice in the
backend code; ERRCODE_CHECK_VIOLATION appears four times;
NOT_NULL_VIOLATION appears five times, as does
ERRCODE_FOREIGN_KEY_VIOLATION.

Lastly, I wonder if this could be useful to GUI tool writers?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support