[
https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778894#comment-16778894
]
Hongze Zhang commented on CALCITE-2846:
---------------------------------------
{quote}
This issue and CALCITE-2876 are talking about adding an operator table for
MySQL. Should it be a new class, MySqlSqlOperatorTable? Let's come to consensus
before we proceed.
{quote}
I've close that issue temporarily.
{quote}There does need to be some means to create an operator table instance
that contains all operators for {{fun=oracle}}, and also some means to create
an operator table instance that contains all operators for
{{fun=standard,oracle,mysql}}.
{quote}
I don't strongly support making a single instance for
{{fun=standard,oracle,mysql}}, because it will be not that simple to deal with
a more complicated one like {{fun=standard,oracle,spatial,mysql}}. Using the
existing {{ChainedSqlOperatorTable}} seems to be enough?
And suppose we are implementing a "single instance" solution, or an
"annotation" solution. or a "sets" solution, should we simplify the current
SqlStdOperatorTable as well as what we are doing on OracleSqlOperatorTable? If
so, how could we ensure backward compatibility for SqlStdOperatorTable? Some
downstream projects' code always take references of operators from the table
directly.
> Document Oracle-specific functions, such as NVL and LTRIM, in the SQL
> reference
> -------------------------------------------------------------------------------
>
> Key: CALCITE-2846
> URL: https://issues.apache.org/jira/browse/CALCITE-2846
> Project: Calcite
> Issue Type: Improvement
> Components: site
> Reporter: Julian Hyde
> Assignee: Hongze Zhang
> Priority: Major
> Labels: documentation
>
> Document Oracle-specific functions (DECODE, NVL, LTRIM, RTRIM, SUBSTR,
> GREATEST, LEAST) in the [SQL
> reference|https://calcite.apache.org/docs/reference.html].
> Same goes for MySQL-specific functions (e.g. JSON_TYPE).
> I don't think we should have separate lists of Oracle-specific functions and
> MySQL-specific functions. Because quite a few functions appear in more than
> one place. Better, I think, to have a concise annotation against each
> function which tables it occurs in.
> The current list of tables is standard, oracle, spatial, mysql. Perhaps also
> indicate whether a function is an extension to the SQL standard but still
> occurs in Calcite's default table.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
