"...different capabilities depending on database” What exactly do you mean by “database”? If I create a Calcite model that has one schema backed by a Postgres JDBC catalog and another schema backed by a MySQL JDBC catalog, what “database” would you expect a connection to this model to have?
Calcite has words for these concepts, but I would like you to do the research, find similar Jira cases, and use the right words for these concepts. Julian > On Mar 8, 2024, at 1:40 PM, James Duong <james.du...@improving.com.INVALID> > wrote: > > 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
