[
https://issues.apache.org/jira/browse/CALCITE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031609#comment-16031609
]
Julian Hyde commented on CALCITE-1798:
--------------------------------------
We could have a mechanism where there can be multiple handlers to unparse
calls. Maybe a handler can identify itself as handling a particular dialect, or
a particular set of operators. Or maybe it doesn't, and we use a [chain of
responsibility|https://en.wikipedia.org/wiki/Chain-of-responsibility_pattern],
stopping when we find a handler. And I suppose handlers could be loaded from
the classpath the same way that JDBC drivers are. Feel free to log a new JIRA
case with a proposed mechanism.
> In JDBC adapter, generate dialect-specific SQL for FLOOR operator
> -----------------------------------------------------------------
>
> Key: CALCITE-1798
> URL: https://issues.apache.org/jira/browse/CALCITE-1798
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
> Reporter: Chris Baynes
> Assignee: Julian Hyde
> Labels: dialect
> Fix For: 1.13.0
>
>
> The FLOOR operator (on dates) is currently broken for all jdbc dialects.
> The syntax allowed by the parser looks like: "FLOOR(datetime to timeUnit)".
> However no jdbc dialect (as far as I'm aware) actually name the function
> FLOOR:
> In postgres: DATE_TRUNC('year', my_datetime)
> In hsqldb: TRUNC ( my_datetime, 'YYYY' )
> In oracle: TRUNC(my_datetime, 'YEAR')
> In mysql: There's no direct equivalent in mysql (though it could be emulated
> with some nasty timestamp diffing)
> The other issue is that the timeUnits are sometimes also named differently by
> each dialect (e.g. 'YYYY' in hsqldb).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
