Re: SQL conformity regarding SQLSTATE
От
Tom Lane
Тема
Re: SQL conformity regarding SQLSTATE
Дата
Msg-id
11558.1513819695@sss.pgh.pa.us
Ответ на
Re: SQL conformity regarding SQLSTATE (Jürgen Purtz)
Список
Дерево обсуждения
SQL conformity regarding SQLSTATE Jürgen Purtz <juergen@purtz.de>
Re: SQL conformity regarding SQLSTATE Tom Lane <tgl@sss.pgh.pa.us>
Re: SQL conformity regarding SQLSTATE Jürgen Purtz <juergen@purtz.de>
Re: SQL conformity regarding SQLSTATE Tom Lane <tgl@sss.pgh.pa.us>
Re: SQL conformity regarding SQLSTATE Jürgen Purtz <juergen@purtz.de>
Re: SQL conformity regarding SQLSTATE Tom Lane <tgl@sss.pgh.pa.us>
Re: SQL conformity regarding SQLSTATE Jürgen Purtz <juergen@purtz.de>
Re: SQL conformity regarding SQLSTATE Simon Riggs <simon@2ndquadrant.com>
=?UTF-8?Q?J=c3=bcrgen_Purtz?= writes: > Summary: 01008, 03000, 0B000, 39001, F0000, and F0001 do not conform to > the standard. I poked around in SQL:2011 and I concur that the first four of those no longer appear in the standard. However, unless grep is failing me, we aren't generating those errcodes anywhere either: ERRCODE_WARNING_IMPLICIT_ZERO_BIT_PADDING ERRCODE_SQL_STATEMENT_NOT_YET_COMPLETE ERRCODE_INVALID_TRANSACTION_INITIATION ERRCODE_E_R_I_E_INVALID_SQLSTATE_RETURNED So we could just remove those codes and be no worse off. As for the other two, ERRCODE_CONFIG_FILE_ERROR and ERRCODE_LOCK_FILE_EXISTS, we certainly are using those, but as I mentioned it seems somewhat unlikely that clients are testing for them. I'm tempted to propose renumbering them as PF000 and PF001. regards, tom lane
В списке pgsql-sql по дате отправления