[
https://issues.apache.org/jira/browse/PHOENIX-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15631003#comment-15631003
]
Maryann Xue commented on PHOENIX-3355:
--------------------------------------
Two things:
1. The reason why ToDateFunction takes two extra arguments aside from the list
is that at "parse" time the last two parameters have been pre-processed and
thus have become two independent arguments. I think in this case it would make
more sense to change the constructor signature back to taking a list only and
to process the last two arguments within the constructor. This would avoid
having to have special handling for each individual function such as
ToDateFunction. Meanwhile, in order to process the last two arguments,
"dateFormat" and "timeZoneId", we need a StatementContext, or essentially the
PhoenixConnection's properties. So I think we can allow two types of signatures
for Function constructors:
a) XXXFunction(List<Expression>)
b) XXXFunction(List<Expression>, StatementContext)
Then it would only require an if-else in {{constructUDFFunction()}}.
2. Optimally we should have a StatementContext object in
{{PhoenixImplementorImpl}} so that it can be used by the function translation.
It has been a question there for a while, but we'll figure it out.
[~lomoree] and [~jamestaylor], what do you think about (1)? Can all built-in
functions be solved that way?
> Register Phoenix built-in functions as Calcite functions
> --------------------------------------------------------
>
> Key: PHOENIX-3355
> URL: https://issues.apache.org/jira/browse/PHOENIX-3355
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Eric Lomore
> Labels: calcite
> Attachments: PHOENIX-3355.wip, PHOENIX-3355.wip2
>
>
> We should register all Phoenix built-in functions that don't exist in Calcite.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
