From DOUGLAS.SURBER at oracle.com Thu Apr 4 17:52:42 2019 From: DOUGLAS.SURBER at oracle.com (Douglas Surber) Date: Thu, 4 Apr 2019 10:52:42 -0700 Subject: [jsr-221-eg] SQL 2016 MATCH RECOGNIZE JDBC parameter Marker / Escape Characters In-Reply-To: <9b8935c0-9415-80fc-3d50-a955aca7b28a@lawinegevaar.nl> References: <9091F6E1-1268-454C-A8F0-9755AA1F9EFA@oracle.com> <15A33956-0D1F-43DC-BEA3-F200DD41D7D2@oracle.com> <950b4f91-b3bb-32a3-b1c1-15c0ae6154d3@lawinegevaar.nl> <97764AA3-9934-4196-A603-41C164A45C8E@oracle.com> <23DE1231-8A2A-4D12-880A-1FA2AE6D8832@oracle.com> <567f97b2-5e1a-3802-4b03-cfe94599edd9@lawinegevaar.nl> <047A178F-167C-41B8-8BAB-20439AA780B1@oracle.com> <73A4B8F0-AA6E-458D-9FC8-99DCCE446BED@oracle.com> <6bdfefeb-8bfe-073e-922d-19cd4f1296af@lawinegevaar.nl> <84E5B171-FF49-45CB-9BE0-FCDCE46D9B90@oracle.com>

<37EC273D-AF66-4B14-A785-1DB97E88AAE4@oracle.com> <1669E279-D3F1-4B15-9008-D5281D80FF04@oracle.com> <9b8935c0-9415-80fc-3d50-a955aca7b28a@lawinegevaar.nl> Message-ID: <02A84BD1-1DE7-438B-9269-82E95085036A@oracle.com> Oracle informally raised this idea at a recent meeting of SC32/WG3. "WG3 agreed to consider such a proposal if made." The SQL spec already specifies meaning for '{', '}', and '?'. More syntax is coming that uses these and other tokens that will conflict with JDBC and might conflict with various JDBC implementations. WG3 has informally agreed to consider reserving some tokens for use by preprocessors, such as JDBC, to escape conflicting preprocessor syntax. Obviously WG3 has the dominant role in this process, but Oracle would like the JDBC EG to reach consensus before Oracle makes a formal proposal to WG3. To that end Oracle proposes that tokens '{\' and '\}' be used to indicate subsequences of SQL tokens that are not scanned for JDBC escape sequences. These are SQL tokens and are not recognized in SQL literals, SQL quoted identifiers or SQL comments. If the underlying database does not use '?' as a parameter marker, a '?' between these tokens is not replaced with the underlying database's parameter marker. A '\' between these tokens must be doubled. Doubled '\' between these tokens are replaced with a single '\' by a JDBC implementation. An undoubled '\' between such tokens results in a SQLException. Java requires that '\' in String literals be doubled, so a Java String literal would look like " ... {\\ ...\\\\ ... \\} ... ". javac would resolve the doubling required by String literal syntax. It would also resolve any ambiguity caused by Java character escape sequences, eg " ... \t ... ". The '\' before the 't' in the String literal would not appear in the String value as it is Java syntax and javac would resolve the character escape into a TAB character. As has been thoroughly discussed previously, Oracle is not particularly open to alternatives and for this we apologize. Oracle tried to reach consensus with the JDBC EG prior to adding this to the Oracle Database JDBC drivers, but such consensus was not forthcoming, on Oracle's proposal or any alternative. In order to support Oracle's customers we had to move forward even without EG agreement. Since no alternative had any more (or even as much support as) Oracle's proposal, this is what Oracle implemented. Yes, this is not the way the process should work. We will try to be more proactive about proposed changes in the future. In return we hope the JDBC EG and wider community can respond more quickly, recognizing that our industry sometimes moves very quickly. Douglas > On Nov 3, 2018, at 6:43 AM, Mark Rotteveel > wrote: > > On 2-11-2018 18:24, Douglas Surber wrote: >> The proposal is that text between ?{\? and ?\}? is not processed to recognize and expand JDBC specific syntax. In particular this means JDBC escape sequences and ??? parameter markers. ?{\? and ?\}? are not recognized inside comments, literals or double quoted identifiers. Occurrences of ?\? between ?{\? and ?\}? other than inside comments, literals, or double quoted identifiers are doubled. It is vendor dependent whether use of ?{\? and ?\}? is required. If an implementation can distinguish JDBC tokens from SQL tokens without ?{\? and ?\}? they may be omitted. An implementation must support their use even if not required. >> Examples: >> String literal character sequence >> ?{\\ foo \\}? ? foo ? >> ?{\\ {ts '1999-01-09 20:11:11.123455?} \\} ? {ts '1999-01-09 20:11:11.123455?} ? >> ?{\\ ? \\}? ? ? ? >> ?{\\ \\\\ \\}? ? \ ? >> ?{\\ /* \\} */ \\}? ? /* \} */ ? >> ?{\\ // \\} \n \\}? ? // \} ? ? >> ?{\\ ?\\}? \\}? ? ?\}? ? >> ?{\\ q?{\\ foo \\}? \\} ? q?{\ foo \}? ? >> ?{\\ \?\\}\? \\}? ? ?\}? ? >> ?{\\ \\ \\}? SQLException > > In above examples, the fancy quotes (??) need to be replaced with '. > >> I have discussed this with some folks from Oracle?s SQL standards team. They think it is reasonable to have the SQL standard somehow reserve this syntax in the SQL spec for use by preprocessors. I think there is a good chance that the JDBC EG and the SQL Standard Committee can agree on a syntax and reserve it in SQL. We should be able to solve this problem once and for all. >> There are more additions coming to SQL that use ???, ?{?, and ?}?. This problem will just get worse. >> There is at least one open issue. Should the JDBC spec say anything about how ??' would be handled by implementations where the underlying database uses ??? as a parameter marker? It might be reasonable to say that any ??? that is a parameter marker must not be escaped. Whether or not a ??? that is not a parameter marker must be escaped is vendor dependent. > > For database systems that use ? as a parameter marker, escaping ? or not would not really be relevant, as `where x = ?` and `where x = {\?\}` would result in the same query sent and prepared. On the other hand, for database systems that use an alternate parameter marker, the first would work and the second would likely be a syntax error. > > It might be advisable to explicitly state that question marks intended as parameter markers must not be escaped, and question marks not intended as parameter markers should be escaped (difference between 'must not' and 'should' intentional to allow leniency for implementations where there would be no ambiguity and escaping would not be necessary). > >> Consider a database that uses ??? as a parameter marker and supports MATCH RECOGNIZE. The SQL syntax is such that the database can distinguish between a parameter marker and a quantifier. This requires a full SQL parser. By including the above restrictions a driver can scan the SQL for parameter markers without implementing a full SQL parser or being tripped up by a ??? used as a quantifier. The JDBC should say something, at least that it is vendor dependent. It would be better though to give users specific direction. > > See above. > > Other than that, I'm okay with this. > > Mark > > -- > Mark Rotteveel From frank at dexels.com Mon Apr 22 09:09:05 2019 From: frank at dexels.com (Frank Lyaruu) Date: Mon, 22 Apr 2019 11:09:05 +0200 Subject: Confused about RowPublisherOperation usage in ADBA Message-ID: Hey all, I'm trying to create a reactive-backpressure demo using ADBA. It pretty much got it working with pgadba, but I'm a little bit confused about the way I'm supposed to be using the API: In RowPublisherOperation: public RowPublisherOperation subscribe(Flow.Subscriber subscriber,CompletionStage result); What is the purpose of the 'result' CompletionStage? I'm getting the results through the subscriber. When the query completes, the subscriber gets a completed signal, so I don't see the use of it. If I pass an empty new CompletableFuture<>() to it, and ignore it after that it seems to work but I'm unsure if that is correct and it won't be leaking something somewhere. Similarly, can I safely ignore the completionstage of the submission? It seems I've got all the information I need from the subscriber stream. RowProcessor rp = new RowProcessor(); > final CompletableFuture completableFuture = > session.rowPublisherOperation("select title from film") > .subscribe(rp, result) > .submit() > .getCompletionStage() > .toCompletableFuture(); > Moreover, if I want to cancel this stream, do I need to cancel both the subscriber and the submission? Or is cancelling the subscriber enough? The mix of Flow and CompletionStages makes my head hurt a bit.