[
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:41 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. {SET
search_path}} can change this behavior.
- Thus, priority is given to making builtins behave the same in every keyspace,
over preserving application compatibility if a new builtin is added.
Presumably if someone's application is broken by a new builtin, he can change
search_path to prioritize his own.
TLDR I'm pretty strongly in favor of attaching functions to keyspaces like
this. I don't really care whether we search current ks before or after system.
(If we choose to search system first, then we still don't need to provide a
search_path mechanism until the next release when new builtins are added.)
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()}}), 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.
> 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)
