From: Chapman Flack <chap@anastigmatix.net>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: generate documentation keywords table automatically
Date: Mon, 29 Apr 2019 15:19:02 -0400
Message-ID: <f9bf4ea8-b6ea-e61e-1f76-94c7dc5738c2@anastigmatix.net> (raw)
In-Reply-To: <fd3df804-bf09-2b08-264b-c4985d25ded1@2ndquadrant.com>
References: <07daeadd-8c82-0d95-5e19-e350502cb749@2ndquadrant.com>
<21977.1556378722@sss.pgh.pa.us>
<fd3df804-bf09-2b08-264b-c4985d25ded1@2ndquadrant.com>
On 4/29/19 2:45 PM, Peter Eisentraut wrote:
>> A policy issue, independent of this mechanism, is how many different
>> SQL spec versions we want to show in the table.
>
> We had previously established that we want to show 92 and the latest
> two. I don't propose to change that.
An annoying API requirement imposed by the JDBC spec applies to its
method DatabaseMetaData.getSQLKeywords():
It is required to return a list of the keywords supported by the DBMS
that are NOT also SQL:2003 keywords. [1]
Why? I have no idea. Were the JDBC spec authors afraid of infringing
ISO copyright if they specified a method that just returns all the
keywords?
So instead they implicitly require every JDBC developer to know just
what all the SQL:2003 keywords are, to make any practical use of the
JDBC method that returns only the keywords that aren't those.
To make it even goofier, the requirement in the JDBC spec has changed
(once, that I know of). It has been /all the keywords not in SQL:2003/
since JDBC 4 / Java SE 6 [2], but before that, it (the same method!)
was spec'd to return /all the keywords not in SQL92/. [3]
So the ideal JDBC developer will know (a) exactly what keywords are
SQL92, (b) exactly what keywords are SQL:2003, and (c) which JDBC
version the driver in use is implementing (though, mercifully, drivers
from pre-4.0 should be rare by now).
If the reorganization happening in this thread were to make possible
run-time-enumerable keyword lists that could be filtered for SQL92ness
or SQL:2003ness, that might relieve an implementation headache that,
at present, both PgJDBC and PL/Java have to deal with.
Regards,
-Chap
[1]
https://docs.oracle.com/en/java/javase/12/docs/api/java.sql/java/sql/DatabaseMetaData.html#getSQLKey...)
[2]
https://docs.oracle.com/javase/6/docs/api/index.html?overview-summary.html
[3]
https://docs.oracle.com/javase/1.5.0/docs/api/index.html?overview-summary.html
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: chap@anastigmatix.net, peter.eisentraut@2ndquadrant.com, tgl@sss.pgh.pa.us
Subject: Re: generate documentation keywords table automatically
In-Reply-To: <f9bf4ea8-b6ea-e61e-1f76-94c7dc5738c2@anastigmatix.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox