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

Julian Hyde commented on CALCITE-5280:
--------------------------------------

{quote}
Notice that I had to remove one of the existing ST_UNION function (due to a 
name clash?). Also, this function is not implemented in postgis.
{code}
 @SemiStrict public static Geometry ST_Union(Geometry geomCollection) {
    return geomCollection.union();
 }
{code}
{quote}

I agree that it's confusing to have regular and aggregate functions named 
{{ST_Union}}. (Not just confusing for humans - the validator needs to decide 
whether a query is implicitly an aggregate query due to the presence of 
aggregate functions.) H2GIS, at least, [has 
both|http://www.h2gis.org/docs/dev/ST_Union/]. Do you recommend that were 
rename the regular (non-aggregate) function to {{ST_UnaryUnion}}? I could 
support that.

> Implement geometry aggregate functions
> --------------------------------------
>
>                 Key: CALCITE-5280
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5280
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: Bertil Chapuis
>            Assignee: Bertil Chapuis
>            Priority: Minor
>              Labels: pull-request-available
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Geometry aggregate functions (ST_Accum, ST_Collect, and ST_Union) are 
> currently missing in Calcite. Using an AggregateFunctionImpl looks be pretty 
> straightforward, but many aggregate function implement SqlAggFunction 
> directly.
> [~julianhyde] What would be the best way to implement them?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to