On Fri, 17 Oct 2025 22:12:25 GMT, Lance Andersen <[email protected]> wrote:

>> This PR adds support for the upcoming JDBC 4.5 MR which provides the 
>> following  updates to the JDBC specification:
>> 
>> - Deprecate SQLPermission for removal
>> - Enhance the Blob/Clob/Array/SQLXML/NClob interfaces to extend/support 
>> AutoClosable
>> - Add the SQL types DECFLOAT, JSON to Types.Java and JDBCType.java
>> - Add the quoted identifier methods that **were added previously to the 
>> Statement interface in JDK 9** to the Connection interface
>>   - It is the exact same verbiage & default methods used when these methods 
>> were added to the Statement interface
>> - Clarify the Timestamp::hashCode method which incorrectly indicates that 
>> nanos are not used when calculating the hash
>> 
>> Tiers 1-3 have been run
>
> Lance Andersen has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Minor wordsmithing based on approved CSR feedback

src/java.sql/share/classes/java/sql/Connection.java line 1708:

> 1706:      * JDBC driver implementations may need to provide their own 
> implementation
> 1707:      * of this method in order to meet the requirements of the 
> underlying
> 1708:      * datasource.

I realize this is how Statement.enquoteLiteral is specified since its 
introduction in JDK 9 but I can't see how a JDBC driver has any leeway to 
effect a different outcome. The spec is very clear that it quotes the input and 
replaces any single quotes with two single quotes. Do you have any examples 
where a "requirement" from a datasource could result in a different outcome? I 
could imagine a driver implementation doing its own implementation for 
performance reasons but not sure beyond that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27693#discussion_r2442855186

Reply via email to