cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8053) Support for user defined aggregate functions
Date Fri, 21 Nov 2014 12:12:34 GMT

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

Sylvain Lebresne commented on CASSANDRA-8053:
---------------------------------------------

Regarding the syntax above, as far as I can tell, Postgres syntax doesn't have a {{FINALTYPE}},
they infer it from {{FINALFUNC}} (or from {{STYPE}} if there is no {{FINALFUNC}}). So I'd
rather not adding something useless. Now, Postgres is not terribly consistent in that {{STYPE}}
is arguably also dispensable since by definition it should be the type of the first argument
of {{SFUNC}}. So I'd get rid of it too and make the syntax be simply: {noformat}
CREATE AGGREGATE <aggregateName>(<param-type...>)
     SFUNC <name-of-state-function>
     [ FINALFUNC <name-of-final-function> ]
     [ INITCOND <term> ]
{noformat}


Other than that, 2 general comment from a (very quick, not really a review) read of the patch
* I'd really rather not save both scalar and aggregate functions in the same system table.
Let's just add a new system table for aggregates that have just the info that an aggregate
function need.
* I'm not sure how fan I am of the delayed resolution of functions. I understand the problem
it's trying to solve, that an aggregate definition may reach a node before the definition
of the scalar function it uses, but I'm not sure it's worth adding complexity for that. This
problem is not different from trying to create a table after it's keyspace, or an index after
it's table, and the status quo is that it's the job of the client to wait for schema agreement
before moving on with DML definitions. I'd rather use the same assumption here.


> Support for user defined aggregate functions
> --------------------------------------------
>
>                 Key: CASSANDRA-8053
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8053
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Robert Stupp
>            Assignee: Robert Stupp
>              Labels: cql, udf
>             Fix For: 3.0
>
>         Attachments: 8053v1.txt
>
>
> CASSANDRA-4914 introduces aggregate functions.
> This ticket is about to decide how we can support "user defined aggregate functions".
UD aggregate functions should be supported for all UDF flavors (class, java, jsr223).
> Things to consider:
> * Special implementations for each scripting language should be omitted
> * No exposure of internal APIs (e.g. {{AggregateFunction}} interface)
> * No need for users to deal with serializers / codecs



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message