[
https://issues.apache.org/jira/browse/CASSANDRA-11946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15772466#comment-15772466
]
Benjamin Lerer commented on CASSANDRA-11946:
--------------------------------------------
{quote}The main use case I'm thinking of is the {{now()}} function. Currently,
we have it only for {{timeuuid}}. But we should likely provide the equivalent
for other time-base types ({{timestamp}}, {{date}} and {{time}}). Except that
currently we'd have to use other names that {{now}} and that would probably be
a bit ugly. If we implement what's above, we'll be able to have overloads of
{{now()}} for all date types and in many case it'll work how users want out of
the bose (that is, {{WHERE t = now()}} will work whatever date-based type t
is). And in the cases where you can't disambiguate, having to do
{{(time)now()}} is not really worth than if we had a {{timeNow()}} function
specific to the {{time}} type.{quote}
While trying to add multiple {{now()}} functions, I realized that the problem
was less simple than it mights appear at first. In the case of {{SELECT now()
FROM ...}}, the current resolution algorithm will return the first function
that has matching name and argument types ignoring the other ones completely
instead of asking to disambiguate. Using a hint (e.g. {{SELECT (timestamp)
now() FROM ...}}) is also not working currently. As type hints were used so far
only to determine term types and not function output.
I also believe that allowing functions with the same arguments and only
different return type will require some big changes for {{UDF}}/{{UDA}}.
Another problem is that adding multiple {{now()}} functions is a breaking
change. Some queries might stop working (even if using {{now()}} in a
{{SELECT}} clause look weird).
After looking at all that, I start to believe that we should not allow to
overload only the return type. Using it to try to disambiguate is a good thing
(and we should probably fix the type hint issue) but I do not think that we
should go further.
I had a look at Oracle, PostgreSQL, Transact-SQL and MySQL and they all use
{{CURRENT_TIMESTAMP}},{{CURRENT_DATE}} and {{CURRENT_TIME}}. As we have not
used underscore in our function names so far I think we should probably use
{{currentTimestamp}},{{currentDate}} and {{currentTime}} instead.
> Use the return type when resolving function on ambiguous calls
> --------------------------------------------------------------
>
> Key: CASSANDRA-11946
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11946
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
> Reporter: Sylvain Lebresne
>
> Currently, when we have multiple overloads of a function we only use the
> argument to try to resolve the function. When that resolution is ambiguous,
> we currently throw an error, but in many case (in the {{WHERE}} clause at
> least) we know which type the result is supposed to be so we could use that
> information to try to disambiguate.
> The main use case I'm thinking of is the {{now()}} function. Currently, we
> have it only for {{timeuuid}}. But we should likely provide the equivalent
> for other time-base types ({{timestamp}}, {{date}} and {{time}}). Except that
> currently we'd have to use other names that {{now}} and that would probably
> be a bit ugly. If we implement what's above, we'll be able to have overloads
> of {{now()}} for all date types and in many case it'll work how users want
> out of the bose (that is, {{WHERE t = now()}} will work whatever date-based
> type {{t}} is). And in the cases where you can't disambiguate, having to do
> {{(time)now()}} is not really worth than if we had a {{timeNow()}} function
> specific to the {{time}} type.
> Also, in principle the change is just a few lines of code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
