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#getSQLKeywords()
[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