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
