On 2019-10-22 11:13, Lukas Eder wrote:
Have you considered exposing or using the JDBC escapes like
TIMESTAMPDIFF and then leave it up to the driver to provide the
translation? That does assume that drivers implement those JDBC
escapes,
but it is required for the Java EE support level of a driver.
I really don't like those escapes.
To be honest, I never use them. I only know about them for the fun (not
entirely ironic) I had (re)implementing them in Jaybird.
1) They're very poorly supported
2) They're very incomplete (why are there escapes for 1-2 features,
but not the gazillion other ones?)
As I understand it, historically they are derived from ODBC (like a lot
of other things in JDBC). I guess that when writing the first ODBC
specification they took a cross-section of what most databases at that
time had in some form or another, and came up with escapes for those
features to allow a unified access. JDBC just copied that. See
https://docs.microsoft.com/en-us/sql/odbc/reference/appendixes/odbc-escape-sequences?view=sql-server-ver15
and
https://docs.microsoft.com/en-us/sql/odbc/reference/appendixes/appendix-e-scalar-functions?view=sql-server-ver15
and compare that against the JDBC specification.
From the perspective of JDBC, there probably won't be new JDBC escapes,
except something in the next JDBC revision (whenever that arrives) to
mark sections of SQL as 'pass-through' without processing to address
parser problems for drivers of databases where the native parameter
marker is not a question mark, where parts of their syntax also uses
question marks.
The primary opinion from the JDBC EG is that databases should use SQL
standard syntax.
Mark
--
You received this message because you are subscribed to the Google Groups "jOOQ User
Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jooq-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jooq-user/f36a882c9554ff28287a07214c7af16b%40lawinegevaar.nl.
