[
https://issues.apache.org/jira/browse/CASSANDRA-7395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14063932#comment-14063932
]
Tyler Hobbs commented on CASSANDRA-7395:
----------------------------------------
A few comments:
* We should move the javassist work to a new ticket. Let's keep CASSANDRA-7526
for js/nashorn and use a different ticket for Java.
* Regarding function definition syntax, I would prefer to stick a little closer
to the SQL standard. There are two main changes for that:
** Use the {{RETURNS}} keyword to declare the return type. For example,
{{CREATE FUNCTION foobar(val double) RETURNS double}}.
** Declare the language for the function with the {{LANGUAGE}} keyword. For
example, {{CREATE FUNCTION foobar(val double) RETURNS double LANGUAGE java
...}}. For the java class case, the language would not be declared.
* {{DROP TYPE}} statements need to also check UDFs to make sure they're not
used as a parameter or return type.
* On the topic of UDTs, I presume we'll require them to always be
keyspace-qualified when used with UDFs.
* I like the idea of being able to namespace functions, but I'm not sold on the
concept of bundles. What's the advantage of having bundles over just
namespacing functions like {{CREATE FUNCTION namespace::function...}}? I think
this would be simpler and introduce fewer new concepts for users to grok.
* The primary key for system.schema_functions can be {{((namespace, name),
signature)}}.
* +1 on {{CREATE OR REPLACE FUNCTION}} (matches postgres)
* I think we'll want separate permissions for defining and executing functions
instead of reusing CREATE permissions. I'll create a new ticket for that.
* We can move cqlsh updates to a separate ticket as well.
* As far as converting types for function arguments goes, I suppose we do need
to go ahead and either pull in the java driver as a dependency or reuse the
data type classes. (Having the java driver be able to build a separate data
types jar would be ideal.) Is that something you want to try to tackle?
There's lots more to cover for this ticket, but that's a start.
> Support for pure user-defined functions (UDF)
> ---------------------------------------------
>
> Key: CASSANDRA-7395
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7395
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Labels: cql
> Fix For: 3.0
>
> Attachments: 7395.txt
>
>
> We have some tickets for various aspects of UDF (CASSANDRA-4914,
> CASSANDRA-5970, CASSANDRA-4998) but they all suffer from various degrees of
> ocean-boiling.
> Let's start with something simple: allowing pure user-defined functions in
> the SELECT clause of a CQL query. That's it.
> By "pure" I mean, must depend only on the input parameters. No side effects.
> No exposure to C* internals. Column values in, result out.
> http://en.wikipedia.org/wiki/Pure_function
--
This message was sent by Atlassian JIRA
(v6.2#6252)
