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