Incidentally, in the PR that added the FloorCeil approach, it was suggested based on the SqlStdOperatorTable.like(boolean, boolean) function.
However I don’t see this method referenced anywhere in either the parser or regular Java code, and if I delete it, the project still builds. I also don’t see it referenced in the PR it was introduced in so it appears to be superfluous? I must be missing something – is this invoked with reflection somewhere? Thanks From: James Duong <james.du...@improving.com.INVALID> Date: Friday, March 8, 2024 at 12:12 PM To: dev@calcite.apache.org <dev@calcite.apache.org> Subject: Supporting a function with different capabilities depending on database Hi Calcite dev, I’m working on adding support for more PostgreSQL functions based on PostgreSQL 14 – See https://issues.apache.org/jira/browse/CALCITE-6308. Some functions such as LOG have different semantics depending on which database is used: * In PostgreSQL, LOG with one argument is to base e while in BigQuery it is to base 10. * In PostgreSQL, LOG with two arguments has the arguments in the reverse order as BigQuery. Other functions support fewer arguments depending on the database: * REGEXP_LIKE in PostgreSQL allows an optional extra parameter to specify a string of flags. What would be the right way to model this? Would an approach similar to FLOOR/CEIL be best? In that, if the parser encounters FLOOR/CEIL arguments, it calls a function which returns a different SqlOperator depending on the conformance for the parser. Thanks, James
