Re: Bug in AbstracJdbc2Statement.replaceProcessing when using dollar quoting?

> Hi Dave,
> I don't want this feature removed. I just would like to see this fixed so
that
> dollar quoted strings are correctly seen as strings, and therefor without
sql
> escape clauses replacing. Like the comment for replaceProcessing says
"look
> through non-string sql code". Dollar quoted strings are strings for
postgresql.
>

But they are not "strings" for JDBC.  The JDBC syntax is a distinct entity
and if you use JDBC features you are expected to adhere to its standards.

Furthermore, the code comment in the driver does not constitute the
canonical behavior of the JDBC specification.

Regardless of whether the JDBC specification addresses what a valid "string
delimiter" is the fact remains that such a definition has to be made at the
JDBC level if the definition is used to implement a JDBC-only feature.

Since unquoted identifiers can include the dollar-sign in PostgreSQL a
broader analysis of the entire query is going to be required.  It would
behoove whoever decides to implement this to look and see exactly how
PostgreSQL itself handles identification of dollar-quoting versus
dollar-including-identifiers.

The semantics and definition, though, are pretty much meaningless.  Someone
still has to actually code an implementation regardless of whether it is a
"bug" or a "enhancement".  Or, as mentioned before, you can simply fix your
own environment so that you can enable or disable escape processing as you
deem necessary.  I still feel that mixing the two behaviors is wrong and no
attempt to do so should be made.  At best identify that mixing has occurred
and thrown an exception.  At worse ignore the escapes and let the database
inform the user of their error.

From the lack of other responses so far I do not see that you have much
choice other than to code something yourself.  It is up to you to decide
whether to simply fix the artificial limitations imposed by your own
development environment (and thus disable escape processing for your
queries) or whether you want to attempt to improve the driver and thus share
your efforts with the rest of the community.  Or maybe fund the improvement
of the driver by someone else.  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.

The main issue I see here is that the behavior change probably isn't that
bad to code.  The performance implications of such a change - which impacts
every single query to determine whether it uses dollar-quoting - would be
the biggest concern.  To avoid this impact it is reasonable for the driver
to simply provide an API so that user can tell it when dollar-quoting is in
use and when it is not (again, a hybrid approach is not worthwhile).  If the
user has to deal with queries where it is unknown (and the decision is
important) they can code whatever pre-processor algorithm they feel is
appropriate to make that determination for their own project.

David J.