Github user maryannxue commented on the issue:
https://github.com/apache/phoenix/pull/222
No differentiation between the regex functions (String based and Byte based)
-- Let's just add support for this one?
Invert and MD5 Function don't work (phoenix doesn't supply the correct
arguments in annotation)
-- Can we make it right, or is it more complicated than that? If the
latter, we can open another issue.
Type matching doesn't work on input arguments (date/timestamp)
-- It's probably a Calcite issue. Let's try repo it as a Calcite test case.
Let me know if you need help working with Calcite unit tests.
Timezone parameter doesn't work properly in ToDateFunction (basic cases
work, but custom timezones do not act as expected)
I probably know this one. Not sure if this is the issue though: the
date/time/timestamp objects are local time (w/ timezone offset) in
Calcite/Avatica, while they are UTC time on the Phoenix side.
Array constructors are not supported (another issue entirely)
-- Yes, another issue. We could open a JIRA listing those test failures
blocking on this issue as a way to keep track of them.
As to the code refinement, I think there are 4 (maybe more?) big chunks of
code: createBuiltinFunctions(), evaluateReturnType(), overloadArguments() and
registerBuiltinFunctions(). We should probably put all these in one place. I
prefer in PhoenixSchema, otherwise CalciteUtils could also do. What makes sense
to where the code should live, aside from what class of object it instantiates,
is also who is the caller or who decides the logic or routines. So it seems to
me that PhoenixScalarFunction here is only the "callee" class which is used by
PhoenixSchema and CalciteUtils.
There are a couple of things here that eventually forms the complete list
of functions that we register in Calcite:
1. We create multiple signatures corresponding to each overload of the same
function.
2. We merge all versions of the same signature but with different default
parameter counts into one function.
3. We deal with aliases.
Part of the reason why we are doing this is that we are trying to
reorganize the existing function dictionary into something that would match the
Calcite conventions. The implementation could end up being very different if
the existing Phoenix function structure were something else. So I guess it'd be
easier to maintain if we put these methods all in one place and maybe we should
add more code comment describing what each of these methods do.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
