[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777040#comment-16777040 ] Hongze Zhang commented on CALCITE-2846: --- I'll take this. > 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: Bug >Reporter: Julian Hyde >Assignee: Hongze Zhang >Priority: Major > > 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16777847#comment-16777847 ] Stuti Gupta commented on CALCITE-2846: -- There are certain operators which are present in multiple dialects but are not part of SqlStdOperatorTable. So to avoid duplicating these operators in multiple dialect specific OperatorTables, I propose that, Creating a CommonSqlOperatorTable, which will have functions/operators that are common in more than one dialect. In the CommonSqlOperatorTable, the functions will have an annotation which will take the list of dialects to which it belongs. Also, there will be a wrapper SqlOperatorTable that will take the CommonSqlOperatorTable and an accompanying dialect, and all lookups via the ChainedSqlOperatorTable will go via this wrapper/delegator. This class will simply filter out those operators that do not equal the dialect with which it has been initialized. I would like to know your views on this approach. > 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[
https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778541#comment-16778541
]
Julian Hyde commented on CALCITE-2846:
--
I mostly agree:
* It makes sense to have a "holder" class for these operator instances.
CommonSqlOperatorTable will serve that purpose.
* I don't feel strongly either way whether there should be a class for each
DBMS flavor, e.g. {{OracleSqlOperatorTable}}. 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}}.
* Let's make sure that we don't create and populate an operator table every
time a query is prepared. Making operator tables immutable and caching them
based on flavor, e.g. {{"standard", "oracle", "mysql"}}, might make sense.
* Note that the operator table is not determined by dialect. It would be
possible to use the MySQL dialect (e.g. identifiers quoted by back-ticks) in
combination with an operator table that contains all Oracle-specific functions.
> 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778550#comment-16778550 ] Julian Hyde commented on CALCITE-2846: -- Regarding annotations. We clearly need to make it reasonably easy to add a particular function to a particular flavor. E.g. we want to add the NVL function to the Teradata flavor. But I don't want to make it *too* easy. I would like to see a code change where someone made that decision to add NVL to Teradata. I don't want functions to appear in flavors because someone forgot to exclude them. By all means create sets of functions, if it makes things easier to manage (e.g. LTRIM and RTRIM could be in the same set) > 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16778546#comment-16778546 ] Julian Hyde commented on CALCITE-2846: -- Both issues are talking about adding an operator table for MySQL. Should it be a new class, MySqlSqlOperatorTable? Let's come to consensus before we proceed. > 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[
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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806346#comment-16806346 ] Hongze Zhang commented on CALCITE-2846: --- I see this issue has been mentioned in CALCITE-2965 as likely a blocker. But unfortunately I am not currently working on this so I have unassigned myself from the issue. If would be much appreciated if someone decide to help then. > 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808539#comment-16808539 ] Stuti Gupta commented on CALCITE-2846: -- [~Chunwei Lei], I will take this change of creating a CommonSqlOperatorTable, which will have functions/operators that are common in more than one dialect. The approach is that, based on the annotations on the functions in the CommonSqlOperatorTable, it will create pre-built operator tables for dialects set in CalciteConnectionProperty FUN and chain them together. > 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 >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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16809475#comment-16809475 ] Chunwei Lei commented on CALCITE-2846: -- [~stutigupta], sure. Please feel free to let me know if I can help. > 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 >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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16811398#comment-16811398 ] Hongze Zhang commented on CALCITE-2846: --- Thank you very much [~stutigupta]! And please improve the title (or summary as well) to match the change needed once you have a clear plan. Currently it looks to be all about site/document changes for only Oracle dialect functions. > 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 >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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16819780#comment-16819780 ] Forward Xu commented on CALCITE-2846: - Reference blink now is to write its own FlinkSqlOperatorTable class, which function to use, directly from StandardXX OracleXXX reference. That's pretty clear. In fact, this practice links the function chains of different databases together. > 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 >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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823488#comment-16823488 ] Julian Hyde commented on CALCITE-2846: -- [~stutigupta], Any progress on this? I'd love to get this into 1.20. There are quite a few issues (e.g. JSON_xxx functions) blocked on this. If it helps, we could split this into two tasks: 1. re-organize SqlOperatorTable, 2. re-organize reference.md. Let me know. > 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 >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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16823614#comment-16823614 ] Danny Chan commented on CALCITE-2846: - [~julianhyde] i would like to take this issue. > 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 >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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824887#comment-16824887 ] Danny Chan commented on CALCITE-2846: - link as a sub task > 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: Danny Chan >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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825697#comment-16825697 ] Danny Chan commented on CALCITE-2846: - [~julianhyde] I have fire a PR [https://github.com/apache/calcite/pull/1181] The main diff is: # Add a SqlDialectOperatorTableFactory to support fetch specific operator table by dialect # Add a annotation SqlDialect to annotate the sql functions declared in SqlDialectOperatorTableFactory # deprecate OracleSqlOperatorTable I also think that we should allow to change the functions dialect too easy, so maybe a sanity check test is needed here. > 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: Danny Chan >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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825715#comment-16825715 ] Chunwei Lei commented on CALCITE-2846: -- Good job, [~danny0405]. I left some comments. > 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: Danny Chan >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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825896#comment-16825896 ] Danny Chan commented on CALCITE-2846: - Thx for your review, [~Chunwei Lei] ! > 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: Danny Chan >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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16828996#comment-16828996 ] Danny Chan commented on CALCITE-2846: - For documentation i have made change for reference.md: [PR#1189|https://github.com/apache/calcite/pull/1189] # Add a new category named *SqlDialect Operators* to list all the sql dialect operators, for every operator, we tag the sql dialects with it. # Move mysql-specific operators to this category > 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: Danny Chan >Priority: Major > Labels: documentation, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16830986#comment-16830986 ] Hongze Zhang commented on CALCITE-2846: --- Thanks [~danny0405]. Can we include the spatial functions in the document changes too? Seems to be a nice addition to have. > 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: Danny Chan >Priority: Major > Labels: documentation, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16832985#comment-16832985 ] Danny Chan commented on CALCITE-2846: - [~zhztheplayer] Does the spatial functions belong to standard flavor now ? I somehow don't know how to re-organize them, do you have any suggestions ? > 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: Danny Chan >Priority: Major > Labels: documentation, pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16833151#comment-16833151 ] Julian Hyde commented on CALCITE-2846: -- Reviewing now. > 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: Julian Hyde >Priority: Major > Labels: documentation, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834980#comment-16834980 ] Julian Hyde commented on CALCITE-2846: -- Almost done. See my branch [https://github.com/julianhyde/calcite/tree/2846-fun-ref] where I have fixed up a bit and added a test (see CALCITE-3053 for details). I will commit when tests pass. > 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: Julian Hyde >Priority: Major > Labels: documentation, pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > 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)
[jira] [Commented] (CALCITE-2846) Document Oracle-specific functions, such as NVL and LTRIM, in the SQL reference
[ https://issues.apache.org/jira/browse/CALCITE-2846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835246#comment-16835246 ] Danny Chan commented on CALCITE-2846: - Thx [~julianhyde], the query demo for oracle `TRANSLATE` is wrong for my previous mistake, i have comment your commit, sorry for that. > 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: Julian Hyde >Priority: Major > Labels: documentation, pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > 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)
