“CORR” is a reserved keyword in the parser because it is a reserved keyword in the SQL:2011 and SQL:2014 draft standards. Even though the aggregate function is not implemented, it’s better that the parser gives an error, so people find out early that “CORR” is a bad name for a table or column.
Can you please log a JIRA case to implement the CORR aggregate function? The work is probably similar to what was done[1] in https://issues.apache.org/jira/browse/CALCITE-422 <https://issues.apache.org/jira/browse/CALCITE-422> to implement REGR_SXX and REGR_SYY. I notice that REGR_SLOPE, REGR_INTERCEPT, REGR_COUNT, REGR_R2, REGR_AVGX, REGR_AVGY, REGR_SXY are not implemented either. Julian [1] https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=af86cd87 <https://git1-us-west.apache.org/repos/asf?p=calcite.git;a=commit;h=af86cd87> > On May 3, 2017, at 4:45 PM, Dmitri Shtilman <[email protected]> wrote: > > Hi all, > > A quick question regarding CORR(x,y). > It appears that Calcite recognizes "CORR" a reserved keyword but the parser > doesn't recognize it as an aggregate, like for example COVAR_POP. Could > CORR be added to the list of recognized aggregates? > > Thanks, > Dmitri > > > ERROR-- Parse failed: line 1, column 8, Encountered "CORR" at line 1, column > 8. > Was expecting one of: > "UNION" ... > "INTERSECT" ... > ... > "COVAR_POP" ... > "COVAR_SAMP" ... > ...
