SQL 2016 MATCH RECOGNIZE JDBC parameter Marker / Escape Characters

[Douglas Surber]

I would like to believe that the database vendors/members of the SQL working group can insure that a reasonable JDBC escape syntax is never part of the SQL language. I wouldn’t suggest that the SQL working group would accept just anything we proposed, but with a little internal communication I think we should be able to reach consensus between the JDBC EG and our representatives to the SQL WG. 

Ideally the SQL standard would state that <whatever syntax> is reserved for preprocessors. At worst the major vendors would have a gentleman’s agreement that the SQL standard would never accept <whatever syntax> as valid SQL. This seems very doable.

A vendor could add a proprietary extension that used <whatever syntax>, but that’s a footgun.

Douglas

> On Oct 9, 2018, at 4:48 AM, Lance Andersen <lance.andersen at oracle.com> wrote:
> 
>> On Oct 9, 2018, at 3:29 AM, Lukas Eder <lukas.eder at gmail.com <mailto:lukas.eder at gmail.com>> wrote:
>> 
>> I have two comments on this:
>> 
>> 1. Expecting the "unexpected", how would you go about escaping the escape sequence? If {\...\} is ever something we would like to send to the server "AS IS", without being processed, how could that be done?
> 
> Agree it is un-likely but should be considered.  Assuming there is not a better solution for disabling parameter markers/escape processing  found for a segment of a PreparedStatement,  the sequence could be doubled  up which is pretty ugly.
> 
> Definitely needs more thought
> 
>