Re: Bug in AbstracJdbc2Statement.replaceProcessing when using dollar quoting?
От | David Johnston |
---|---|
Тема | Re: Bug in AbstracJdbc2Statement.replaceProcessing when using dollar quoting? |
Дата | |
Msg-id | 00f501cd9bf7$57195dc0$054c1940$@yahoo.com обсуждение исходный текст |
Ответ на | Bug in AbstracJdbc2Statement.replaceProcessing when using dollar quoting? (GEISINGER Marc - Contractor <Marc.GEISINGER@external.thalesgroup.com>) |
Ответы |
Re: Bug in AbstracJdbc2Statement.replaceProcessing when
using dollar quoting?
(GEISINGER Marc - Contractor <Marc.GEISINGER@external.thalesgroup.com>)
|
Список | pgsql-jdbc |
> -----Ursprüngliche Nachricht----- > Von: David Johnston [mailto:polobo@yahoo.com] > Gesendet: Montag, 24. September 2012 17:49 > An: GEISINGER Marc - Contractor; 'Dave Cramer' > Cc: pgsql-jdbc@postgresql.org > Betreff: RE: [JDBC] Bug in AbstracJdbc2Statement.replaceProcessing when > using dollar quoting? > > > > At worse even if you cannot code it yourself you can propose pseudo- > code/algorithm that people could review and then someone could just code > > and deploy. > > Looking at > http://www.postgresql.org/docs/9.1/static/sql-syntax-lexical.html > > 4.1.1. Identifiers and Key Words > ... > SQL identifiers and key words must begin with a letter (a-z, but also letters > with diacritical marks and non-Latin letters) or an underscore (_). Subsequent > characters in an identifier or key word can be letters, underscores, digits (0- > 9), or dollar signs ($). Note that dollar signs are not allowed in identifiers > according to the letter of the SQL standard, so their use might render > applications less portable. > > it seems to me, that $ are not allowed as identifiers by the SQL standard. But > they are allowed in postgresql. But also in postgresql they are not allowed at > the beginning of an identifier. > As far as I understand the parseSql method (line 864) in > AbstractJdbc2Statement class, the looking for a dollar quoted string could be > done similar to the looking for escape codes (line 894). > If we are IN_SQLCODE and we find a '$' as character, look through the > following chars until the next '$' is found. Anything between the two '$' is the > tag. Then we would have a state IN_DOLLARQOUTE, until we find this '$tag$' > again. > The only problem I see with this idea might come from nested dollar quotes. > > Marc Which is why my suggestion is possibly superior and at least simpler (thus less prone to bugs). Once you find the non-conforming dollar-quote start tag in the query simply abort the JDBC specific code and return the query unmodified. As I mentioned in a separate post a dollar-sign cannot begin the identifier while it must begin the dollar-quote so we should be able to unambiguously determine which of the two options is valid upon encountering a dollar-sign without having to perform any further scan. You now remove the "information losing" quality of the current behavior. I'm personally willing to risk the breakage of existing mixed code on the basis that such mixing is inconsistent with the goal of the standard in the first place and thus is likely to be minimal at best. As a middle ground the rest of the query should be scanned for JDBC escapes and, if found (anywhere, even inside a dollar-quoted string), a RuntimeException sub-class should be thrown pointing out the use of "mixed syntax". That aside, nested quoting is not a concern; the string literal does not end until the matching ending tag is found (i.e., at no point after encountering a dollar-quote start tag does the parser state become IN_SQLCODE - until the closing quote is matched). David J.
В списке pgsql-jdbc по дате отправления:
Следующее
От: GEISINGER Marc - ContractorДата:
Сообщение: Re: Bug in AbstracJdbc2Statement.replaceProcessing when using dollar quoting?