[jsr-221-eg] SQL 2016 MATCH RECOGNIZE JDBC parameter Marker / Escape Characters

[Lance Andersen]

> On Oct 9, 2018, at 3:35 PM, Mark Rotteveel <mark at lawinegevaar.nl> wrote:
> 
> 
> 
>> In 2013 when we added this to the Oracle Database JDBC driver, we thought it was the best choice available lacking consensus from the JDBC EG. We still think it is the best choice. Oracle Database JDBC must continue to support this going forward. Our preference would be for this to be added to the JDBC standard. We have no fundamental objection to additional syntax to meet specific needs. We would rather not to add both the proposed syntax and some equivalent alternate syntax as that would be unnecessary duplication. We would very much prefer that our proposed syntax be part of the standard though we will consider alternatives.
> 
> I understand that, and I'll agree - with a bit of protest and moaning ;) - to this syntax if the syntax specification is further clarified/formalized. As I said, we should avoid https://xkcd.com/927/.
> 
> However, I want to repeat my concern that this is not a thing of beauty, and introducing features this way should be avoided in the future. Especially as something that was apparently rejected by the EG (or at least, not accepted), is now reintroduced as a fait accompli now MATCH_RECOGNIZE is standardized in SQL:2016.

Well with the SQL Standard evolving to include MATCH RECOGNIZE, this is now an issue  to discuss as it will impact any vendor implementing this standard operator.  The discussion was tabled in 2013 , primarily due to the issue not being impacted  by the SQL Standard so it was not of importance to the EG members at that time.

Brody, Mark, has Progress updated their Oracle drivers to support MATCH RECOGNIZE and if so how are you dealing with this issue?  Volker what about your inet Oracle Driver?

The decision can still be to do nothing, come up with a different syntax and/or alternative.  This is not the first time a spec, not just JDBC,  has revisited a discussion that was tabled.

> 
> We should also consider explicitly allowing vendor escapes in the specification, so vendors know that they can always introduce a workaround that does not interfere with future specification/standardization (see http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2013-February/000059.html). For example, Oracle could have used {oracle \...\} as a solution when the EG did not accept its previous proposal.

> 
> Mark
> -- 
> Mark Rotteveel

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>