SQL conformity regarding SQLSTATE
От | Jürgen Purtz |
---|---|
Тема | SQL conformity regarding SQLSTATE |
Дата | |
Msg-id | c2c1a96d-dae9-6667-bf11-eb423ee90385@purtz.de обсуждение исходный текст |
Ответы |
Re: SQL conformity regarding SQLSTATE
|
Список | pgsql-sql |
Hello, SQLSTATE is defined by the SQL standard. Our usage of the value seems to contain some defects in respect to it: SQLCODE is divided into a *class* (first two bytes) and a *subclass* (next 3 bytes). If an implementation defines additional values to support its own non- standardised features, it must use values within the two ranges [5-9] or [I-Z] for the first byte of the class *or* the first byte of the subclass. Our preferred byte for this case is P. But there are cases where other decisions have taken place. Here is a list of values, which violate the above rule as the values are in the range which is reserved for the standard but (actually) are not defined by the standard. I compared our list in the version 10 documentation with the SQL:2011 standard. (Unfortunately I have no access to SQL:2016. Maybe, some values of my list are defined there.) 01008, 03000, 0B000, 23502 - 23514, 39001, 42501 - 42939, F0000, F0001. With that said I have some questions: a) We strive for standard conformity as well as for continuity in our product. How can we solve that conflict? b) Shall we add a comment into 'errcodes.txt' to remind everybody to the mentioned rule? c) Is it possible to rearrange the rows of 'errcode.txt' in a way that reflects the natural sort order of SQLSTATE? This will be helpful for reading Appendix A of our documentation which is generated out of 'errcode.txt'. But: a lot of other Postgres parts depends on this file - may be, some unwanted side effects will arise? d) Do we have representatives in ISO's national bodies (ANSI, DIN, BSI, ...) to follow and influence the standardisation process? Jürgen Purtz
В списке pgsql-sql по дате отправления: