Sylvain Lebresne created CASSANDRA-7813:
-------------------------------------------

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

Reply via email to