[
https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14162602#comment-14162602
]
Robert Stupp commented on CASSANDRA-7813:
-----------------------------------------
Comments on current status in git branch so far:
* Had to add {{-Xmaxinlinedfastates 10}} for {{Cql.g}} generation after a small
change - otherwise javac complained with {{javac: CqlParser.java:1423: error:
code too large}} because {{unaliasedSelector()}} had more than 13000 lines
* Did not use the 'current keyspace' (that selected using {{USE}}) but the
keyspace of the selected table. Reason is that it would require a lot of
refactoring in a lot of classes to carry {{ClientState}} (or the current
keyspace)) to {{Functions.get()}} - just wanted to know whether that
refactoring is worth the effort. Example:
{code}
CREATE KEYSPACE foobar ...;
CREATE FUNCTION foobar.now() RETURNS timestamp ...;
SELECT now() FROM foobar.some_table ...;
-- executes system now() because now() is not fully qualified an system
functions are searched first
SELECT foobar.now() FROM foobar.some_table ...;
-- executes foobar.now()
CREATE FUNCTION foobar.baz() RETURNS timestamp ...;
USE other_ks;
SELECT baz() FROM foobar.tab ...;
-- executes UDF foobar.baz(), since tab is in KS foobar
{code}
* Changed UDF separator from {{::}} to {{.}}
* UDF creation in {{system}}, {{system_auth}}, {{system_traces}} is not
permitted
> 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
> Assignee: Robert Stupp
> 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.3.4#6332)
