Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eRIcw-0001f4-Br for pgsql-sql@arkaria.postgresql.org; Tue, 19 Dec 2017 14:12:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eRIcv-0002BG-Pf for pgsql-sql@arkaria.postgresql.org; Tue, 19 Dec 2017 14:12:13 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eRIcv-0002B6-Gc for pgsql-sql@lists.postgresql.org; Tue, 19 Dec 2017 14:12:13 +0000 Received: from mout.kundenserver.de ([212.227.17.10]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eRIco-0004yS-7Q for pgsql-sql@lists.postgresql.org; Tue, 19 Dec 2017 14:12:12 +0000 Received: from [192.168.188.21] ([77.176.210.108]) by mrelayeu.kundenserver.de (mreue103 [212.227.15.183]) with ESMTPSA (Nemesis) id 0MLAED-1eR1dq2KJd-000HWg for ; Tue, 19 Dec 2017 15:12:03 +0100 From: =?UTF-8?Q?J=c3=bcrgen_Purtz?= To: pgsql-sql@lists.postgresql.org Subject: SQL conformity regarding SQLSTATE Message-ID: Date: Tue, 19 Dec 2017 15:14:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Provags-ID: V03:K0:P0ZIkLWUBp65UYwxVnvdEm5TrI2Em9IoGprirgQA/hKLfTilQFE 50nTsvNs8GGuaxlpP8iVk8jT5dwlysAFtxFZLisjNy3iWjA2WYg3Nm6qXzIK7bryQQ8mjgK 5UGRxWBdhR92qVj22INOj19JgfOo0/YYZWYwpHTlr24EXgmy0in20BMPYJai6aaka+MRANE fK2w6w3jgVt3NZOnPN0cQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Cv9ybFMuJoA=:kcJtpOevUE1AANIiv1vdFg lTgOqzn9ne8adbQEO6iU8wN67LSOVJsUFsvm9M4rs6Bg7GHSN9op2rIlfrMhKV0nPXSWx8He5 L0g/L5bP1viYWIrg0BEYJlW96BquKMpmpm97ZAUJbMGVeU1kjCKkj7hG/to0/hHJrKJxO7cY8 n/KlTjT+Tmc/kJpfc9/OyUKTQkeeQZiVryHMADan8SRpIPKTTJPm5RTQ/PcGlFujilnlZ+iwG yx2/+p1RQrpc5natdo2W+50HZxPMlTzOtf3cM9wr5pv2s5P7NAGmB4Gnkfmu6oi4j2O8udp25 1J8aiMdN5BdtAMjIwOH3cI6ISUKYjVWPCbXpBnFNpUIrGCWIHdx+PYD07YmnCrX5ujmdcPrmh rSweKsg6bPyzvvLm9haZSsFKvhwMnnYAPAcLWHeVJo2aWZqWFSTgKfEtWI13EYCQxq51Z3iNY u0sMW4UG++v7wgrB1xCkUM+yoai39Rk2dEUdoSINYNFQ/cyRls3uxytHoutnw3i1H4dhpVtim LNKGKD2iAdj4X6lEmfnTZJLmYSbkyFhXn9jPLErV1rwmcghj9vY1AgRAWu79HmIfWKNJODAqc Bri856IDSItQoPyl3VgkABzr00KhFpjuAr2Bee6C5jlTO6h8Qdyu9yIeZRYQWse7lOexzXXnZ fbD7UeopW1xW7GRpaK3GRloJP2+GQ5yWGVvln4V5Ax3UpWkdAUTwOR6Qsv2V4AJQHomp5M06a Ccy2Hz0l9Et4XwqppKrz8G2n4Mg3lpDb1dygqxAHmF0BFlPDsH+MEIe0GTg= List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk 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