[
https://issues.apache.org/jira/browse/CALCITE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16032794#comment-16032794
]
Chris Baynes commented on CALCITE-1798:
---------------------------------------
I'll log another JIRA case with the proposed mechanism.
Just have one other issue with the current implementation - I've just noticed
that the same node can be referenced by different parts of the query.
For example if I add a GROUP BY clause using the same FLOOR operator, the
setOperator call I've used will be applied to the SqlCall of the GROUP BY and
then the unparse method will break when it is called on it later on.
To fix that I'm using clone before setOperator, but needed to adjust the clone
method on SqlBasicCall to make sure it clones the operands too.
The PR is here: https://github.com/apache/calcite/pull/465
> 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)
