Hi Christopher,
> Caveat: if for some reasons "statement.setEscapeProcessing(false)",
> the above syntax would not work.
Interesting!
Currently, jOOQ has full control over statement / prepared statement
creation and the JDBC spec for that method says that the default is
for escape processing to be "on". So unless you will do any magic with
your implementation of the EventListener, this shouldn't be a problem.
I didn't find any corresponding method in the JDBC Connection type,
that could override the default...
> I tried to change in our code base and it failed for that reason. I
> re-activated escape processing because I don't notive any particular
> performance impact but bear this in mind.
Lacking a @since Javadoc tag, I'm guessing that this method originates
from the very early days of JDBC / Java, when string parsing was still
quite expensive. Today, I guess it can be ignored.
Note, that jOOQ is already using using these features:
> - date and time literals
> - calling stored procedures and functions
> - Scalar functions (e.g.: {fn concat("Hot", "Java")})
Function escaping is used with Derby only. These features aren't used:
> - outer joins
> - escape characters for LIKE clauses
I guess that the outer join JDBC escape syntax was introduced to
simulate ANSI outer joins in early versions of Oracle (A.REF_ID (+)=
B.ID)
Cheers
Lukas
