cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Lerer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11946) Use the return type when resolving function on ambiguous calls
Date Fri, 23 Dec 2016 10:05:58 GMT

    [ 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)

Mime
View raw message