[CALCITE-216] Inconsistent use of provided operator table causes inability to add aggregate functions

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Labels: github-import
• Assignee: Unassigned
• Reporter: GitHub Import
• Created: 18/Jun/14 08:39
• Updated: 18/Jun/14 08:39
• Resolved: 18/Jun/14 08:39

Description

I found this problem when trying to provide an Apache Drill custom aggregate function. Optiq complains that the field referenced inside the aggregate function isn't part of the grouping. Clearly, Optiq isn't recognizing that it is an Aggregate function despite extending from SqlAggFunction.

The Problem: When using frameworks and calling getPlanner(... SqlStdOperatorTable ...) the framework only uses this table for final function resolution. However, initial resolution done in SqlAbstractParserImpl uses the default SqlStdOperatorTable. If this initial resolution fails, the parser creates a SqlBasicCall (which is not an aggregator). Query validation will then fail if the unknown function is used where a grouping context is needed.

At least two options exist:

• modify AbstractParserImpl to leverage the same operator table as provided via the getPlanner() method rather than initializing its own.
• update the validator to try to resolve the function before running AggChecker.

Additional Notes:

• The planner interface is providing requiring a subclass of SqlStdOperatorTable rather than the SqlOperatorTable interface. This makes overriding unnecessarily misleading.
• I believe this can be addressed by creating a custom SqlParser using the recently merged parser factory issue, however that seems like a hack.

Assigning to Julian to get his feedback on approach.

---------------- Imported from GitHub ----------------
Url: https://github.com/julianhyde/optiq/issues/216
Created by: jacques-n
Labels: bug,
Assignee: julianhyde
Created at: Sun Mar 30 21:44:55 CEST 2014
State: closed