[CALCITE-5280] Add geometry aggregate functions (ST_Accum, ST_Collect, and ST_Union)#2989
Conversation
ffdda79 to
a3a7777
Compare
dca5c62 to
05f66fe
Compare
05f66fe to
ebbdb5d
Compare
| import org.apache.calcite.prepare.CalciteCatalogReader; | ||
| import org.apache.calcite.runtime.SpatialTypeFunctions; | ||
| import org.apache.calcite.schema.Function; | ||
| import org.apache.calcite.schema.SchemaPlus; |
There was a problem hiding this comment.
The large number of new imports is an indication that the code to define the aggregate functions should be somewhere else.
There was a problem hiding this comment.
I agree, this code should have been placed in SqlOperatorTables.createSpatial. However, as it does not address the number of imports, I looked at the SqlStdOperatorTable and wondered if we should create a SqlSpatialOperatorTable. I will probably dig into this a bit, but please stop me if it is a bad idea.
There was a problem hiding this comment.
@julianhyde I moved this part of the code to a new class called SqlSpatialTypeOperatorTable, which implements the SqlOperatorTable interface. I also experimented with the ReflectiveSqlOperatorTable, but I believe that using this approach would require declaring properties of type SqlUserDefinedAggFunction for each AggregateFunction. What do you think about continuing down this path?
cef9e87 to
1c78de0
Compare
1c78de0 to
5fefdd8
Compare
Here, the main point of caution is the creation of the operator table in
SqlLibraryOperatorTableFactory.