Re: [BUGS] BUG #14883: Syntax SQL error (42601), but should be a different error no
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #14883: Syntax SQL error (42601), but should be a different error no |
Дата | |
Msg-id | 23556.1509418211@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUGS] BUG #14883: Syntax SQL error (42601), but should be adifferent error no ("David G. Johnston" <david.g.johnston@gmail.com>) |
Ответы |
Re: [BUGS] BUG #14883: Syntax SQL error (42601), but should be adifferent error no
|
Список | pgsql-bugs |
"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
В списке pgsql-bugs по дате отправления: