"David G. Johnston" <david.g.johnston@gmail.com> writes:
> Someone familiar with the SQL standard would need to confirm that our
> choice in this case is not governed by the standard before I'd consider
> changing it.
The SQL committee takes basically no interest in this area: their
taxonomy for syntax & semantic analysis errors consists of
(wait for it...)
Class 42 syntax error or access rule violation
with exactly no standard-defined subclasses. Whatever implementations
do to distinguish different subcategories is up to them (although IIRC
we borrowed some of our subcategories from DB2, so they're not things
we came up with out of noplace).
I agree that there's some case for considering this to be
ERRCODE_DATATYPE_MISMATCH, but I'm not sure that the case is strong
enough to justify a compatibility break from changing it.
More generally, there are a *lot* of ERRCODE_SYNTAX_ERROR calls in
the backend that could arguably be changed to something more specific,
even without inventing any new subcategories for the purpose. If we were
to decide that we're willing to make a compatibility break here, I'd
rather see a patch that goes through all of them and changes what seems
reasonable. Better a big break than drip drip drip ...
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
