cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-7813) Decide how to deal with conflict between native and user-defined functions
Date Sun, 24 Aug 2014 14:35:39 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14108419#comment-14108419
] 

Jonathan Ellis edited comment on CASSANDRA-7813 at 8/24/14 2:35 PM:
--------------------------------------------------------------------

bq. CQL doesn't have to 100% mimic SQL, but at least learn from it and avoid reinventing the
horse unless there is a clear and compelling benefit to a wide range of developers. If CQL
is going to detour from SQL for some reason, at least clearly refer to the specific SQL rule
and the specific rationale for doing so.

Agreed.  To be specific, here is how postgresql handles this:

- all functions belong to a schema (keyspace).  CREATE FUNCTION follows the same rules as
CREATE TABLE (explicit ks is allowed; otherwise uses current ks)
- built-in functions belong to the {{pg_catalog}} schema, analogous to our {{system}} ks
- on function invocation without an explicit ks ({{SELECT foo()}}), system ks is searched
FIRST, then current ks.  This means that if you want to call an overridden builtin function,
you have opt in to that explicitly.


was (Author: jbellis):
bq. CQL doesn't have to 100% mimic SQL, but at least learn from it and avoid reinventing the
horse unless there is a clear and compelling benefit to a wide range of developers. If CQL
is going to detour from SQL for some reason, at least clearly refer to the specific SQL rule
and the specific rationale for doing so.

Agreed.  To be specific, here is how postgresql handles this:

- all functions belong to a schema (keyspace).  CREATE FUNCTION follows the same rules as
CREATE TABLE (explicit ks is allowed; otherwise uses current ks)
- built-in functions belong to the {{pg_catalog}} schema, analogous to our {{system}} ks
- on function invocation without an explicit ks ({{SELECT foo()}}), current ks is searched
for {{foo}}, then system ks.

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

Mime
View raw message