[
https://issues.apache.org/jira/browse/CALCITE-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Dennis updated CALCITE-7599:
----------------------------------
Description:
There is a small inconsistency remaining between the reference documentation
[https://calcite.apache.org/docs/reference.html#syntax] and the parser syntax.
The documentation example shows unquoted numeric literals being used as values
in a key-value hint. The reference documentation use this as an example query:
{code:sql}
SELECT /*+ hint1, hint2(a=1, b=2) */
...
FROM
tableName /*+ hint3(5, 'x') */
JOIN
tableName /*+ hint4(c=id), hint5 */
...
{code}
The unquoted literals in {{hint2(a=1, b=2)}} do not parse using the current
grammar however, and are not present in copy of the documentation query used in
SqlHintsConverterTest#testDocumentationExample}}. I think it should be pretty
simple to expand the grammar to support the same set of literals as is
currently supported by {{ParenthesizedLiteralOptionCommaList}}, that is
{{StringLiteral | NumericLiteral}} (in addition to the {{SimpleIdentifier}}
that is currently also supported for the value of a key-value pair). At the
same time we should update the test so that the query exactly matches the
documentation example by not quoting the two numeric constants. To be clear
that means both signed, and unsigned; integers, decimals and scientific
notation. The following therefore are all valid numeric literals: {{1}},
{{-1}}, {{1.1}}, {{-1.1}}, {{1.2e3}}, {{-1.2e-5}}.
was:
There is a small inconsistency remaining between the reference documentation
[https://calcite.apache.org/docs/reference.html#syntax] and the parser syntax.
The documentation example shows unquoted numeric literals being used as values
in a key-value hint. The reference documentation use this as an example query:
{code:sql}
SELECT /*+ hint1, hint2(a=1, b=2) */
...
FROM
tableName /*+ hint3(5, 'x') */
JOIN
tableName /*+ hint4(c=id), hint5 */
...
{code}
The unquoted literals in {{hint2(a=1, b=2)}} do not parse using the current
grammar however, and are not present in copy of the documentation query used in
SqlHintsConverterTest#testDocumentationExample}}. I think it should be pretty
simple to expand the grammar to support the same set of literals as is
currently supported by {{ParenthesizedLiteralOptionCommaList}}, that is
{{StringLiteral | NumericLiteral}} (in addition to the {{SimpleIdentifier}}
that is currently also supported for the value of a key-value pair). At the
same time we should update the test so that the query exactly matches the
documentation example by not quoting the two numeric constants. To be clear
that means:
[-]
> Enhance parser to allow numeric literals as values in k/v hints as suggested
> by documentation
> ---------------------------------------------------------------------------------------------
>
> Key: CALCITE-7599
> URL: https://issues.apache.org/jira/browse/CALCITE-7599
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.42.0
> Reporter: Chris Dennis
> Priority: Minor
> Labels: pull-request-available
>
> There is a small inconsistency remaining between the reference documentation
> [https://calcite.apache.org/docs/reference.html#syntax] and the parser
> syntax. The documentation example shows unquoted numeric literals being used
> as values in a key-value hint. The reference documentation use this as an
> example query:
> {code:sql}
> SELECT /*+ hint1, hint2(a=1, b=2) */
> ...
> FROM
> tableName /*+ hint3(5, 'x') */
> JOIN
> tableName /*+ hint4(c=id), hint5 */
> ...
> {code}
> The unquoted literals in {{hint2(a=1, b=2)}} do not parse using the current
> grammar however, and are not present in copy of the documentation query used
> in SqlHintsConverterTest#testDocumentationExample}}. I think it should be
> pretty simple to expand the grammar to support the same set of literals as is
> currently supported by {{ParenthesizedLiteralOptionCommaList}}, that is
> {{StringLiteral | NumericLiteral}} (in addition to the {{SimpleIdentifier}}
> that is currently also supported for the value of a key-value pair). At the
> same time we should update the test so that the query exactly matches the
> documentation example by not quoting the two numeric constants. To be clear
> that means both signed, and unsigned; integers, decimals and scientific
> notation. The following therefore are all valid numeric literals: {{1}},
> {{-1}}, {{1.1}}, {{-1.1}}, {{1.2e3}}, {{-1.2e-5}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
