[
https://issues.apache.org/jira/browse/CALCITE-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14990097#comment-14990097
]
Julian Hyde edited comment on CALCITE-950 at 11/4/15 6:27 PM:
--------------------------------------------------------------
It makes sense to add it to the core SQL grammar if as you say it doesn't
conflict with standard SQL. Can you add tests to SqlParserTest including
negative tests and including tests where the JSON map literal looks similar to
an ODBC function?
For each JSON literal there will be an equivalent way to specify it using MAP,
right? If so, at what point does the JSON syntax get expanded? Is it in the
parser, or later?
Since it is an extension I'd like a way to disable it using a
CalciteConnectionProperty flag. I don't mind what component throws the error -
the parser could fail, or the parser could succeed and the validator fail - but
people should be able to request core SQL. However, it is a nice feature and
I'd enable this by default in Calcite.
What are your plans for other JSON syntax, e.g. lists?
Would the atoms inside JSON literals be JSON atoms or SQL atoms? They are the
same in most cases but would character strings be double-quoted or
single-quoted? Would you allow CAST and DATE 'yyyy-mm-dd' and binary literals
and the string concatenation operator?
Would these be true literals (i.e. constant values) or would you allow function
calls and references to column values?
was (Author: julianhyde):
It makes sense to add it to the core SQL grammar if as you say it doesn't
conflict with standard SQL. Can you add tests to SqlParserTest including
negative tests and including tests where the JSON map literal looks similar to
an ODBC function?
For each JSON literal there will be an equivalent way to specify it using MAP,
right? If so, at what point does the JSON syntax get expanded? Is it in the
parser, or later?
Since it is an extension I'd like a way to disable it using a
CalciteConnectionProperty flag. I don't mind what component throws the error -
the parser could fail, or the parser could succeed and the validator fail - but
people should be able to request core SQL. However, it is a nice feature and
I'd enable this by default in Calcite.
What are your plans for other JSON syntax, e.g. lists?
Would the atoms inside JSON literals be JSON atoms or SQL atoms? They are the
same in most cases but would character strings be double-quoted or
single-quoted? Would you allow CAST and DATE 'yyyy-mm-dd' and binary literals
and the string concatenation operator?
> Add Support for JSON Literals in SQL Grammar
> --------------------------------------------
>
> Key: CALCITE-950
> URL: https://issues.apache.org/jira/browse/CALCITE-950
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Jacques Nadeau
> Assignee: Julian Hyde
>
> I've had a patch currently in a Drill branch that adds support for JSON Map
> literals in the SQL Grammar. I'm thinking that I should add this to Calcite
> rather than as an extension. It's only conflicts with ODBC syntax stuff and
> I've managed that by choosing the ODBC parsing paths first (so as not to
> cause regressions). If others are in support, I'll rework the patch to be
> directly against Calcite. [~jul...@hydromatic.net], I imagine you'll be the
> most opinionated about this so I'd like to get your thoughts before I rework
> the patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
