phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maryann Xue (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3355) Register Phoenix built-in functions as Calcite functions
Date Thu, 03 Nov 2016 00:18:58 GMT


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:
>             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

View raw message