[ 
https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16779056#comment-16779056
 ] 

Julian Hyde commented on CALCITE-2846:
--------------------------------------

There a couple of ways you could approach it. You could have pre-built operator 
tables for standard, oracle, mysql, and chain them together. Or you could use a 
builder that creates a new operator table containing the union of the 
operators. Both approaches would work. Pick whichever you prefer.

It's OK to use references to operators (e.g. SqlStdOperatorTable.EQUALS) if 
they are standard and guaranteed to be available. Referencing operator 
instances from other operator tables might cause problems; suppose, for 
example, Oracle and MySQL both have an NVL operator but with different 
semantics. So, for dialect-specific operators I'd recommend looking them up by 
name.

> 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)

Reply via email to