> if the validator encounters an operator, it looks (by name) for the operator
> in the currently active library to see if it is available, then tries to
> resolve arguments and return values
Yes, that is pretty much correct. Except that there can be several
active libraries, so the validator
I’m referring to using the “fun” connection property and setting it to
‘postgresql’, which enables PostgreSQL built-in functions and operators.
I believe this is referred to as a “library” as well.
I saw this SOUNDEX PR and think it covers what I’m looking for:
"...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?
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
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
