[
https://issues.apache.org/jira/browse/PHOENIX-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15765179#comment-15765179
]
Maryann Xue commented on PHOENIX-3355:
--------------------------------------
I have split [~lomoree]'s patch into two parts, one for master branch and the
rest for calcite branch. The changes to master branch are intended to solve 3
main issues:
1. Function initialization should go through either factory methods or
constructors but no long through ParseNode create() method. Right now we do use
constructors, and we allow two types of signatures for function class
constructors {{ctor(List<Expression> children)}} or {{ctor(List<Expression>
children, StatementContext context)}}.
2. Function signature matching will be handled by Calcite so the new code path
should no longer include switch case in ParseNode create() method. So we need a
way to get to those concrete function classes directly, and that's why
annotations have been added to those concrete function classes and we have a
new annotation illustrating if it is a super or a derived function class or an
alias function class.
3. We need a different function map for reorganizing default value function
signatures to match the Calcite function signature lookup interface, as well as
for the above 2 points.
[~jamestaylor], could you please review the pull request for master branch
https://github.com/apache/phoenix/pull/228？
> 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.function_constructor.patch,
> 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)
