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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
