[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14105607#comment-14105607
]
Tyler Hobbs commented on CASSANDRA-7813:
----------------------------------------
There was [some
discussion|https://issues.apache.org/jira/browse/CASSANDRA-7395?focusedCommentId=14083132&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14083132]
of this on CASSANDRA-7395.
I would be in favor of option #3. To disagree with my previous comment linked
above, I think always requiring a namespace is a better solution. This is
primarily so that working CQL statements won't be broken by an upgrade.
bq. We could even allow that namespace to be empty as long as we force the
namespace separator (so we'd allow bar::foo and ::foo for user functions, but
not foo which would be reserved for native function).
I'm -0 on accepting an empty namespace if we require them. It seems like an
extra grammar oddity that doesn't provide much convenience.
> Decide how to deal with conflict between native and user-defined functions
> --------------------------------------------------------------------------
>
> Key: CASSANDRA-7813
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7813
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Labels: cql
> Fix For: 3.0
>
>
> We have a bunch of native/hardcoded functions (now(), dateOf(), ...) and in
> 3.0, user will be able to define new functions. Now, there is a very high
> change that we will provide more native functions over-time (to be clear, I'm
> not particularly for adding native functions for allthethings just because we
> can, but it's clear that we should ultimately provide more than what we
> have). Which begs the question: how do we want to deal with the problem of
> adding a native function potentially breaking a previously defined
> user-defined function?
> A priori I see the following options (maybe there is more?):
> # don't do anything specific, hoping that it won't happen often and consider
> it a user problem if it does.
> # reserve a big number of names that we're hoping will cover all future need.
> # make native function and user-defined function syntactically distinct so it
> cannot happen.
> I'm not a huge fan of solution 1). Solution 2) is actually what we did for
> UDT but I think it's somewhat less practical here: there is so much types
> that it makes sense to provide natively and so it wasn't too hard to come up
> with a reasonably small list of types name to reserve just in case. This
> feels a lot harder for functions to me.
> Which leaves solution 3). Since we already have the concept of namespaces for
> functions, a simple idea would be to force user function to have namespace.
> We could even allow that namespace to be empty as long as we force the
> namespace separator (so we'd allow {{bar::foo}} and {{::foo}} for user
> functions, but *not* {{foo}} which would be reserved for native function).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
