Re: SQL conformity regarding SQLSTATE

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: SQL conformity regarding SQLSTATE
Дата
Msg-id
11558.1513819695@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
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 по дате отправления
От: Simon Riggs
Дата:
От: Jürgen Purtz
Дата:
FAQ