[jira] [Comment Edited] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597567#comment-17597567
]
Danny Chen edited comment on CALCITE-5251 at 8/30/22 6:49 AM:
--
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a{}}} {{{}RelNode{}}}s implements {{Hintable}} is kind of an interval
behavior and should be transparent to users, WDYT ? It's more valuable to
document about the general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {{Hintable}} {}}}we may need
to re-think the design about whether we should abstract out the {{Hintable}} as
base clazz for all the {{RelNodes}} for purpose of hints propagation or
something.
was (Author: danny0405):
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a{}}} {{{}RelNode{}}}s implements {{Hintable}} is kind of an interval
behavior and should be transparent to users, WDYT ? It's more valuable to
document about the general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {{Hintable}}{}}} we may need
to re-think the design about whether we should abstract out the {{Hintable}} as
base clazz for all the {{RelNodes}} for purpose of hints propagation or
something.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current, `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597567#comment-17597567
]
Danny Chen edited comment on CALCITE-5251 at 8/30/22 6:48 AM:
--
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a{}}} {{{}RelNode{}}}s implements {{Hintable}} is kind of an interval
behavior and should be transparent to users, WDYT ? It's more valuable to
document about the general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {{Hintable}}{}}} we may need
to re-think the design about whether we should abstract out the {{Hintable}} as
base clazz for all the {{RelNodes}} for purpose of hints propagation or
something.
was (Author: danny0405):
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a{}}} {{{}RelNode{}}}s implements {{Hintable}} is kind of an interval
behavior and should be transparent to users, WDYT ? It's more valuable to
document about the general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {}}}{{{}Hintable{}}}{{{}{}}}
we may need to re-think the design about whether we should abstract out the
{{Hintable}} as base clazz for all the {{RelNodes}} for purpose of hints
propagation or something.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current, `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597567#comment-17597567
]
Danny Chen edited comment on CALCITE-5251 at 8/30/22 6:48 AM:
--
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a{}}} {{{}RelNode{}}}s implements {{Hintable}} is kind of an interval
behavior and should be transparent to users, WDYT ? It's more valuable to
document about the general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {}}}{{{}Hintable{}}}{{{}{}}}
we may need to re-think the design about whether we should abstract out the
{{Hintable}} as base clazz for all the {{RelNodes}} for purpose of hints
propagation or something.
was (Author: danny0405):
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a{}}} {{{}RelNode{}}}s implements {{Hintable}} is kind of an interval
behavior and should be transparent to users, WDYT ? It's more valuable to
document about the general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {{Hintable}}{}}} we may need
to re-think the design about whether we should abstract out the {{Hintable}} as
base clazz for all the {{RelNodes}} for purpose of hints propagation or
something.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current, `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597567#comment-17597567
]
Danny Chen edited comment on CALCITE-5251 at 8/30/22 6:48 AM:
--
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a{}}} {{{}RelNode{}}}s implements {{Hintable}} is kind of an interval
behavior and should be transparent to users, WDYT ? It's more valuable to
document about the general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {{Hintable}}{}}} we may need
to re-think the design about whether we should abstract out the {{Hintable}} as
base clazz for all the {{RelNodes}} for purpose of hints propagation or
something.
was (Author: danny0405):
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a {}}}{{{}RelNode{}}}{{{}s{}}}{{{}{}}} implements {{Hintable}} is kind
of an interval behavior and should be transparent to users, WDYT ? It's more
valuable to document about the general Hints syntax which we already have on
the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {}}}{{{}Hintable{}}}{{{}{}}}
we may need to re-think the design about whether we should abstract out the
{{Hintable}} as base clazz for all the {{RelNodes}} for purpose of hints
propagation or something.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current, `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597567#comment-17597567
]
Danny Chen edited comment on CALCITE-5251 at 8/30/22 6:47 AM:
--
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a {}}}{{{}RelNode{}}}{{{}s{}}}{{{}{}}} implements {{Hintable}} is kind
of an interval behavior and should be transparent to users, WDYT ? It's more
valuable to document about the general Hints syntax which we already have on
the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {}}}{{{}Hintable{}}}{{{}{}}}
we may need to re-think the design about whether we should abstract out the
{{Hintable}} as base clazz for all the {{RelNodes}} for purpose of hints
propagation or something.
was (Author: danny0405):
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a {{RelNode}}{}}} implements {{Hintable}} is kind of an interval
behavior and should be transparent to users, WDYT ? It's more valuable to
document about the general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {{Hintable}}{}}} we may need
to re-think the design about whether we should abstract out the {{Hintable}} as
base clazz for all the {{RelNodes}} for purpose of hints propagation or
something.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current, `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597567#comment-17597567
]
Danny Chen edited comment on CALCITE-5251 at 8/30/22 6:46 AM:
--
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}{{{}s,
whether a {{RelNode}}{}}} implements {{Hintable}} is kind of an interval
behavior and should be transparent to users, WDYT ? It's more valuable to
document about the general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {{Hintable}}{}}} we may need
to re-think the design about whether we should abstract out the {{Hintable}} as
base clazz for all the {{RelNodes}} for purpose of hints propagation or
something.
was (Author: danny0405):
[~julianhyde] We have not documented specifically for {{RelNode}}s, whether a
{{RelNode}} implements {{Hintable}} is kind of an interval behavior and should
be transparent to users, WDYT ? It's more valuable to document about the
general Hints syntax which we already have on the website.
BTW, more and more {{RelNode}}s implement {{Hintable}} we may need to re-think
the design about whether we should abstract out the {{Hintable}} as base clazz
for all the {{RelNodes}} for purpose of hints propagation or something.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current, `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597567#comment-17597567
]
Danny Chen edited comment on CALCITE-5251 at 8/30/22 6:18 AM:
--
[~julianhyde] We have not documented specifically for {{RelNode}}s, whether a
{{RelNode}} implements {{Hintable}} is kind of an interval behavior and should
be transparent to users, WDYT ? It's more valuable to document about the
general Hints syntax which we already have on the website.
BTW, more and more {{RelNode}}s implement {{Hintable}} we may need to re-think
the design about whether we should abstract out the {{Hintable}} as base clazz
for all the {{RelNodes}} for purpose of hints propagation or something.
was (Author: danny0405):
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}s, whether
a {{RelNode}} implements {{Hintable}} is kind of an interval behavior and
should be transparent to users, WDYT ? It's more valuable to document about the
general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {{Hintable}}{}}}, we may need
to re-think the design about whether we should abstract out the {{Hintable}} as
base clazz for all the {{RelNodes}} for purpose of hints propagation or
something.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current, `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597567#comment-17597567
]
Danny Chen edited comment on CALCITE-5251 at 8/30/22 6:17 AM:
--
[~julianhyde] We have not documented specifically for {{{}RelNode{}}}s, whether
a {{RelNode}} implements {{Hintable}} is kind of an interval behavior and
should be transparent to users, WDYT ? It's more valuable to document about the
general Hints syntax which we already have on the website.
BTW, more and more {{{}RelNode{}}}{{{}s implement {{Hintable}}{}}}, we may need
to re-think the design about whether we should abstract out the {{Hintable}} as
base clazz for all the {{RelNodes}} for purpose of hints propagation or
something.
was (Author: danny0405):
[~julianhyde] We have not documented specifically for RelNodes, whether a
\{{RelNode}} implements \{{Hintable}} is kind of an interval behavior and
should be transparent to users, WDYT ? It's more valuable to document about the
general Hints syntax which we already have on the website.
BTW, more and more \{{RelNode}}s implement \{{Hintable}}, we may need to
re-think the design about whether we should abstract out the \{{Hintable}} as
base clazz for all the \{{RelNode}}s for purpose of hints propagation or
something.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current, `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5251) Support SQL hint for Snapshot
[
https://issues.apache.org/jira/browse/CALCITE-5251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17597567#comment-17597567
]
Danny Chen commented on CALCITE-5251:
-
[~julianhyde] We have not documented specifically for RelNodes, whether a
\{{RelNode}} implements \{{Hintable}} is kind of an interval behavior and
should be transparent to users, WDYT ? It's more valuable to document about the
general Hints syntax which we already have on the website.
BTW, more and more \{{RelNode}}s implement \{{Hintable}}, we may need to
re-think the design about whether we should abstract out the \{{Hintable}} as
base clazz for all the \{{RelNode}}s for purpose of hints propagation or
something.
> Support SQL hint for Snapshot
> -
>
> Key: CALCITE-5251
> URL: https://issues.apache.org/jira/browse/CALCITE-5251
> Project: Calcite
> Issue Type: New Feature
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current, `snapshot` does not support hint yet and this blocks hint
> propagation to the underlying temporal table.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5107) Support SQL hint for Filter, SetOp, Sort, Window, Values
[ https://issues.apache.org/jira/browse/CALCITE-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen resolved CALCITE-5107. - Assignee: Danny Chen Resolution: Fixed Fixed via master c98171da5790d3d5ee7d2eb48a21d0080d0d68f3, thanks for your PR, [~godfreyhe] ~ > Support SQL hint for Filter, SetOp, Sort, Window, Values > > > Key: CALCITE-5107 > URL: https://issues.apache.org/jira/browse/CALCITE-5107 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: godfrey he >Assignee: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.31.0 > > Time Spent: 40m > Remaining Estimate: 0h > > Currently, only part of RelNodes support SQL hint, such as: Scan, Project, > Join. Filter, SetOp, Sort, Window, Values do not support hint yet, which > cause hint propagation can not be supported. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (CALCITE-4967) Support SQL hints for temporal table join
[
https://issues.apache.org/jira/browse/CALCITE-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4967.
-
Fix Version/s: 1.30.0
Resolution: Fixed
Fixed in
[f0bd2b2|https://github.com/apache/calcite/commit/f0bd2b244a4c4b6b89c4133b49d2c7e06b4e1cb6],
thanks for the contribution [~jingzhang] ~
> Support SQL hints for temporal table join
> -
>
> Key: CALCITE-4967
> URL: https://issues.apache.org/jira/browse/CALCITE-4967
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Jing Zhang
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.30.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> h1. Background
> Like hint on join, sometimes we need hint on temporal table join. For
> example, specify USE_HASH hint on temporal table join like the following sql,
> {code:java}
> select /*+ USE_HASH (orders) */ stream * from orders join products_temporal
> for system_time as of orders.rowtime on orders.productid =
> products_temporal.productid
> {code}
> Now, above sql would translate into correlate instead of Join, like the
> following Tree Node.
> {code:java}
> LogicalDelta
> LogicalProject(ROWTIME=[$0], PRODUCTID=[$1], ORDERID=[$2], PRODUCTID0=[$3],
> NAME=[$4], SUPPLIERID=[$5], SYS_START=[$6], SYS_END=[$7])
> LogicalFilter(condition=[=($1, $3)])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
> LogicalTableScan(table=[[CATALOG, SALES, ORDERS]])
> LogicalSnapshot(period=[$cor0.ROWTIME])
> LogicalTableScan(table=[[CATALOG, SALES, PRODUCTS_TEMPORAL]])
> {code}
> However, correlate is not a hintable node now and the hint could not be
> propagated to the correlate nodes.
> So I wonder could we extend correlate to be a hintable node?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4967) Support SQL hints for temporal table join
[
https://issues.apache.org/jira/browse/CALCITE-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17465638#comment-17465638
]
Danny Chen commented on CALCITE-4967:
-
+1 for the idea. We can made the correlate node hintable though.
> Support SQL hints for temporal table join
> -
>
> Key: CALCITE-4967
> URL: https://issues.apache.org/jira/browse/CALCITE-4967
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Reporter: Jing Zhang
>Priority: Major
>
> h1. Background
> Like hint on join, sometimes we need hint on temporal table join. For
> example, specify USE_HASH hint on temporal table join like the following sql,
> {code:java}
> select stream /*+ USE_HASH (orders) */ * from orders join products_temporal
> for system_time as of orders.rowtime on orders.productid =
> products_temporal.productid
> {code}
> Now, above sql would translate into correlate instead of Join, like the
> following Tree Node.
> {code:java}
> LogicalDelta
> LogicalProject(ROWTIME=[$0], PRODUCTID=[$1], ORDERID=[$2], PRODUCTID0=[$3],
> NAME=[$4], SUPPLIERID=[$5], SYS_START=[$6], SYS_END=[$7])
> LogicalFilter(condition=[=($1, $3)])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
> LogicalTableScan(table=[[CATALOG, SALES, ORDERS]])
> LogicalSnapshot(period=[$cor0.ROWTIME])
> LogicalTableScan(table=[[CATALOG, SALES, PRODUCTS_TEMPORAL]])
> {code}
> However, correlate is not a hintable node now. So I wonder could we extend
> correlate to be a hintable node?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4879) Make RelMetadataQuery abstract
[
https://issues.apache.org/jira/browse/CALCITE-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453899#comment-17453899
]
Danny Chen commented on CALCITE-4879:
-
Did you notice that we have a {{MetadataFactory}} that query the metadata using
direct java call(not based on Janino) ?
> Make RelMetadataQuery abstract
> --
>
> Key: CALCITE-4879
> URL: https://issues.apache.org/jira/browse/CALCITE-4879
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
>
> The RelOptCluster.setMetadataQuerySupplier() and RelMedataQuery abstraction
> are great at separating how planners and rules consume metadata versus how
> metadata is produced. While details about how metadata is produced is
> (mostly) not leaked in the api of RelMetadataQuery, the class does assume
> that metadata will be produced via the current mechanisms surrounding
> RelMetadataProviders and MetadataHandlers. This ticket targets separating the
> production of metadata from the consumption interface, by making
> RelMetadataQuery abstract (either as an abstract class or as a interface) and
> moving the handler and provider specific implementations to an implementation
> of RelMetadataQuery. This will allow a broader breadth of experimentation to
> be undertaken. For example, one example people have been evaluating is
> whether a lambda based system would be easier to understand and debug, as
> performant and more AOT friendly than the existing systems of chains and
> janino compilation.
> To accomplish this task, the first step will be to deprecate the existing
> constructors and inform people to use a concrete subtype. Once deprecated,
> the actual logic that currently exists in RelMetadataQuery can be extracted
> into the concrete subtype and the base class can be made either abstract or
> an interface (depending on what seems most appropriate at the time).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (CALCITE-4899) Support hint for lateral table syntax
[
https://issues.apache.org/jira/browse/CALCITE-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453894#comment-17453894
]
Danny Chen edited comment on CALCITE-4899 at 12/6/21, 10:03 AM:
The use case you provide sounds valid from my side, what i'm wondering is if
there is existing vendor has similar syntax for lateral table hints, so that,
when designing the grammar, we can make it more in line with the other vendors,
not to make the syntax looks weird, i mean.
was (Author: danny0405):
The use case you provide sounds valid from my side, what i'm wondering is if
there is existing vendor has similar syntax for lateral table hints, so that,
when design the grammar, we can make it more in line with the other vendors,
not to make to syntax looks weird, i mean.
> Support hint for lateral table syntax
> -
>
> Key: CALCITE-4899
> URL: https://issues.apache.org/jira/browse/CALCITE-4899
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: tartarus
>Priority: Major
>
> I want to add hint for lateral table syntax,
> like this
> {code:java}
> select * from product, lateral table /*+ HINT_NAME(key='value')
> */(RAMP(product.product_id))
> {code}
> then we can pass more information to specific tableFunction
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4899) Support hint for lateral table syntax
[
https://issues.apache.org/jira/browse/CALCITE-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453894#comment-17453894
]
Danny Chen commented on CALCITE-4899:
-
The use case you provide sounds valid from my side, what i'm wondering is if
there is existing vendor has similar syntax for lateral table hints, so that,
when design the grammar, we can make it more in line with the other vendors,
not to make to syntax looks weird, i mean.
> Support hint for lateral table syntax
> -
>
> Key: CALCITE-4899
> URL: https://issues.apache.org/jira/browse/CALCITE-4899
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: tartarus
>Priority: Major
>
> I want to add hint for lateral table syntax,
> like this
> {code:java}
> select * from product, lateral table /*+ HINT_NAME(key='value')
> */(RAMP(product.product_id))
> {code}
> then we can pass more information to specific tableFunction
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4865) Extends Table function to support Polymorphic Table Function
[ https://issues.apache.org/jira/browse/CALCITE-4865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453514#comment-17453514 ] Danny Chen commented on CALCITE-4865: - Hi, [~julianhyde], what do you think about the parser part ? The PR separate the table function parse block out now. > Extends Table function to support Polymorphic Table Function > > > Key: CALCITE-4865 > URL: https://issues.apache.org/jira/browse/CALCITE-4865 > Project: Calcite > Issue Type: Sub-task > Components: core >Reporter: Jing Zhang >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > This Jira aims to extend existed Table function in order to support > Polymorphic Table Function, including: > * Introduces generic input table parameter which has 3 characteristics: > ## Input tables have either row semantics or set semantics) > ### Row semantics means that the the result of the PTF is decided on a > row-by-row basis. > ### Set semantics means that the outcome of the function depends on how the > data is partitioned. > ## The second characteristic, which applies only to input tables with set > semantics, is whether the PTF can generate a result row even if the input > table is empty. > ## The third characteristic is whether the input table supports pass-through > columns or not. Pass-through columns is a mechanism enabling the PTF to copy > every column of an input row into columns of an output row. > * Introduces generic input table parameter which has 3 characteristics: > * Extends `SqlFunction` to support generic input table parameter > * Adds validator for table function > ## only input table parameter with set semantics could be partitioned or > ordered > ## At most has one input table parameter with row semantics > * Updates `Parser.jj` to allow partition by clause and order by clause > follow after input table parameter of table function > * Adds test -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (CALCITE-4879) Make RelMetadataQuery abstract
[
https://issues.apache.org/jira/browse/CALCITE-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453510#comment-17453510
]
Danny Chen commented on CALCITE-4879:
-
> Lack of freedom is a feature.
I have the same concern, the {{RelMetadataQuery}} is not designed to be
sub-classed, if we want to add extensibility to it, i would suggest to add API
for adding new metadata handlers.
> Make RelMetadataQuery abstract
> --
>
> Key: CALCITE-4879
> URL: https://issues.apache.org/jira/browse/CALCITE-4879
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Jacques Nadeau
>Assignee: Jacques Nadeau
>Priority: Major
>
> The RelOptCluster.setMetadataQuerySupplier() and RelMedataQuery abstraction
> are great at separating how planners and rules consume metadata versus how
> metadata is produced. While details about how metadata is produced is
> (mostly) not leaked in the api of RelMetadataQuery, the class does assume
> that metadata will be produced via the current mechanisms surrounding
> RelMetadataProviders and MetadataHandlers. This ticket targets separating the
> production of metadata from the consumption interface, by making
> RelMetadataQuery abstract (either as an abstract class or as a interface) and
> moving the handler and provider specific implementations to an implementation
> of RelMetadataQuery. This will allow a broader breadth of experimentation to
> be undertaken. For example, one example people have been evaluating is
> whether a lambda based system would be easier to understand and debug, as
> performant and more AOT friendly than the existing systems of chains and
> janino compilation.
> To accomplish this task, the first step will be to deprecate the existing
> constructors and inform people to use a concrete subtype. Once deprecated,
> the actual logic that currently exists in RelMetadataQuery can be extracted
> into the concrete subtype and the base class can be made either abstract or
> an interface (depending on what seems most appropriate at the time).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-4899) Support hint for lateral table syntax
[
https://issues.apache.org/jira/browse/CALCITE-4899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453420#comment-17453420
]
Danny Chen commented on CALCITE-4899:
-
Sure, we already support table hints for normal table, searched it roughly and
i did not find any hints on lateral table for popular sql vendors, [~tartarus],
did you find any practical example there ?
> Support hint for lateral table syntax
> -
>
> Key: CALCITE-4899
> URL: https://issues.apache.org/jira/browse/CALCITE-4899
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: tartarus
>Priority: Major
>
> I want to add hint for lateral table syntax,
> like this
> {code:java}
> select * from product, lateral table /*+ HINT_NAME(key='value')
> */(RAMP(product.product_id))
> {code}
> then we can pass more information to specific tableFunction
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (CALCITE-4640) Propagate table scan hints to JDBC
[
https://issues.apache.org/jira/browse/CALCITE-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4640.
-
Fix Version/s: 1.28.0
Resolution: Fixed
Fixed in
[44dfb70|https://github.com/apache/calcite/pull/2426/commits/44dfb709602d822ac681065a31b426de50649351],
thanks for the PR [~kramerul] ~
> Propagate table scan hints to JDBC
> --
>
> Key: CALCITE-4640
> URL: https://issues.apache.org/jira/browse/CALCITE-4640
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.27.0
>Reporter: Ulrich Kramer
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.28.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We would like to use table scan hints to pass [parameters and variables to
> HANA
> views|https://help.sap.com/viewer/88fe5f56472e40cca6ef3c3dcab4855b/2.0.04/en-US/fafb3ea432e54fca9eff11648df5bccd.html].
> It should be possible to convert the following Calcite SQL
> {code}
> SELECT * FROM VIEW /*+ PLACEHOLDERS("$$PARAMETER_1$$"='Test') */
> {code}
> using a special {{SqlDialect}} to a HANA specific statement
> {code}
> SELECT * FROM VIEW ('PLACEHOLDER' = ('$$PARAMETER_1$$', 'Test'))
> {code}
> See also my [mail in the mailing
> list|https://mail-archives.apache.org/mod_mbox/calcite-dev/202105.mbox/%3CD161B82F-5DEC-49A2-A873-4817F4DEB15F%40contoso.com%3E].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3775) Implicit lookup methods in SimpleCalciteSchema ignore case sensitivity parameter
[ https://issues.apache.org/jira/browse/CALCITE-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17372462#comment-17372462 ] Danny Chen commented on CALCITE-3775: - Thanks [~zabetak] for pushing this, prefer 1 if we do not degraded the performance too much. > Implicit lookup methods in SimpleCalciteSchema ignore case sensitivity > parameter > > > Key: CALCITE-3775 > URL: https://issues.apache.org/jira/browse/CALCITE-3775 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.21.0 >Reporter: Stamatis Zampetakis >Priority: Minor > Labels: pull-request-available > Time Spent: 7h 50m > Remaining Estimate: 0h > > SimpleCalciteSchema contains methods for finding tables, sub-schemas, and > types. The API allows to specify if the lookup will be case sensitive or > insensitive but the respective parameter is ignored in the implementation of > the method. > It is not a big problem since most of the time CachingCalciteSchema is used, > which does not have this problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4548) SqlToRelConverter#convertExpression can not convert SqlNode which has subQuery
[
https://issues.apache.org/jira/browse/CALCITE-4548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17342455#comment-17342455
]
Danny Chen edited comment on CALCITE-4548 at 5/11/21, 9:40 AM:
---
Fixed in
[796675c|https://github.com/apache/calcite/commit/796675c9b33e0461bc45a72780162d474a4b098b],
thanks for the PR, [~yr] ~
was (Author: danny0405):
Fixed in
[796675c|[https://github.com/apache/calcite/commit/796675c9b33e0461bc45a72780162d474a4b098b],]
thanks for the PR, [~yr] ~
> SqlToRelConverter#convertExpression can not convert SqlNode which has subQuery
> --
>
> Key: CALCITE-4548
> URL: https://issues.apache.org/jira/browse/CALCITE-4548
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: jibiyr
>Assignee: jibiyr
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> hi community, when I use *SqlToRelConverter* to convertExpression,I found it
> does not registery subQuery before convertExpression, so the
> convertExpression throw npe.
> here is the executable example
>
> {code:java}
> // code placeholder
> CalciterHelper calciterHelper = new CalciterHelper(config);
> SqlNode parse = calciterHelper.parseExpression("ID IN (1, 2, 3)");
> HashMap nameToNodeMap = new HashMap<>();
> nameToNodeMap.put("ID",new RexInputRef(0,
> calciterHelper.getTypeFactory().createSqlType(SqlTypeName.INTEGER)));
> final Map nameToTypeMap = new HashMap<>();
> for (Map.Entry entry : nameToNodeMap.entrySet()) {
> nameToTypeMap.put(entry.getKey(), entry.getValue().getType());
> }
> SqlValidatorImpl orCreateValidator = calciterHelper.getOrCreateValidator();
> orCreateValidator.validateCall((SqlCall) parse,new
> ParameterScope(orCreateValidator,nameToTypeMap));
> SqlToRelConverter orCreateSqlToRelConverter =
> calciterHelper.getOrCreateSqlToRelConverter();
> orCreateSqlToRelConverter.convertExpression(parse,nameToNodeMap);
> {code}
>
>
> and the npe,
>
> {code:java}
> // code placeholder
> Exception in thread "main" java.lang.NullPointerExceptionException in thread
> "main" java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4914)
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4548) SqlToRelConverter#convertExpression can not convert SqlNode which has subQuery
[
https://issues.apache.org/jira/browse/CALCITE-4548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4548.
-
Fix Version/s: next
Resolution: Fixed
Fixed in
[796675c|[https://github.com/apache/calcite/commit/796675c9b33e0461bc45a72780162d474a4b098b],]
thanks for the PR, [~yr] ~
> SqlToRelConverter#convertExpression can not convert SqlNode which has subQuery
> --
>
> Key: CALCITE-4548
> URL: https://issues.apache.org/jira/browse/CALCITE-4548
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: jibiyr
>Assignee: jibiyr
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> hi community, when I use *SqlToRelConverter* to convertExpression,I found it
> does not registery subQuery before convertExpression, so the
> convertExpression throw npe.
> here is the executable example
>
> {code:java}
> // code placeholder
> CalciterHelper calciterHelper = new CalciterHelper(config);
> SqlNode parse = calciterHelper.parseExpression("ID IN (1, 2, 3)");
> HashMap nameToNodeMap = new HashMap<>();
> nameToNodeMap.put("ID",new RexInputRef(0,
> calciterHelper.getTypeFactory().createSqlType(SqlTypeName.INTEGER)));
> final Map nameToTypeMap = new HashMap<>();
> for (Map.Entry entry : nameToNodeMap.entrySet()) {
> nameToTypeMap.put(entry.getKey(), entry.getValue().getType());
> }
> SqlValidatorImpl orCreateValidator = calciterHelper.getOrCreateValidator();
> orCreateValidator.validateCall((SqlCall) parse,new
> ParameterScope(orCreateValidator,nameToTypeMap));
> SqlToRelConverter orCreateSqlToRelConverter =
> calciterHelper.getOrCreateSqlToRelConverter();
> orCreateSqlToRelConverter.convertExpression(parse,nameToNodeMap);
> {code}
>
>
> and the npe,
>
> {code:java}
> // code placeholder
> Exception in thread "main" java.lang.NullPointerExceptionException in thread
> "main" java.lang.NullPointerException
> at java.util.Objects.requireNonNull(Objects.java:203)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.convertExpression(SqlToRelConverter.java:4914)
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4559) Create 'interface RexRule', a modular rewrite for row-expressions
[
https://issues.apache.org/jira/browse/CALCITE-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324379#comment-17324379
]
Danny Chen edited comment on CALCITE-4559 at 4/18/21, 1:21 AM:
---
> should it include NullAs
NullAs simplification is a big scope for rex optimization, I think that is a
must, further more, we should include the rules defined in {{Strong}}.
Another question: what is the relationship between this new rule and the
{{RexSimplify}}, is the {{RexSimplify}} deprecated ?
was (Author: danny0405):
> should it include NullAs
NullAs simplification is a big scope for rex optimization, I think that is a
must, further more, we should include the rules defined in {{Strong}}.
> Create 'interface RexRule', a modular rewrite for row-expressions
> -
>
> Key: CALCITE-4559
> URL: https://issues.apache.org/jira/browse/CALCITE-4559
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> We propose to add {{class RexRule}}, a rewrite rule for row-expressions
> ({{class RexNode}}).
> {{class RexRule}} is analogous to how {{class RelRule}} (and the older
> {{class RelOptRule}}) operates on relational expressions ({{interface
> RelNode}}). Also, {{class RexRuleProgram}} is analogous to {{HepProgram}} and
> {{VolcanoPlanner}} (it indexes rules so that we do not have to try every rule
> against every part of the expression). And a rule describes which operands it
> matches using {{RexRule.describe(RexRule.OperandBuilder)}}, similar to
> calling {{RelRule.Config.operandSupplier().apply()}}.
> The advantages of {{RexRule}} are similar to {{RelRule}}: rules can be
> defined in a modular way, can be documented and tested individually, and can
> be enabled individually.
> The rules could be applied in various ways. {{RelBuilder.Config}} could
> contain a {{RexRuleProgram}} that would be applied every time an expression
> is simplified by a {{RelBuilder}}. There could also be a sub-class of
> {{interface RelShuttle}} that applies the rules to every {{RexNode}} in a
> tree (e.g. inside {{Filter}}, {{Project}} and {{Join}}).
> I don't yet know whether, or how, rules might support 3-valued boolean logic
> ({{RexUnknownAs}}). For example, a rule that simplifies "x = x" to "TRUE" is
> valid in an "unknownAsFalse" context (e.g. as top-level of {{Filter}}
> condition), but not in an "unknownAsUnknown" context (e.g. in {{Project}}
> expression).
> This case is related to CALCITE-3470 (making relational and row-expression
> rules more similar, as in CockroachDB), but would deliver an API rather than
> a textual DSL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4559) Create 'interface RexRule', a modular rewrite for row-expressions
[
https://issues.apache.org/jira/browse/CALCITE-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324379#comment-17324379
]
Danny Chen commented on CALCITE-4559:
-
> should it include NullAs
NullAs simplification is a big scope for rex optimization, I think that is a
must, further more, we should include the rules defined in {{Strong}}.
> Create 'interface RexRule', a modular rewrite for row-expressions
> -
>
> Key: CALCITE-4559
> URL: https://issues.apache.org/jira/browse/CALCITE-4559
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> We propose to add {{class RexRule}}, a rewrite rule for row-expressions
> ({{class RexNode}}).
> {{class RexRule}} is analogous to how {{class RelRule}} (and the older
> {{class RelOptRule}}) operates on relational expressions ({{interface
> RelNode}}). Also, {{class RexRuleProgram}} is analogous to {{HepProgram}} and
> {{VolcanoPlanner}} (it indexes rules so that we do not have to try every rule
> against every part of the expression). And a rule describes which operands it
> matches using {{RexRule.describe(RexRule.OperandBuilder)}}, similar to
> calling {{RelRule.Config.operandSupplier().apply()}}.
> The advantages of {{RexRule}} are similar to {{RelRule}}: rules can be
> defined in a modular way, can be documented and tested individually, and can
> be enabled individually.
> The rules could be applied in various ways. {{RelBuilder.Config}} could
> contain a {{RexRuleProgram}} that would be applied every time an expression
> is simplified by a {{RelBuilder}}. There could also be a sub-class of
> {{interface RelShuttle}} that applies the rules to every {{RexNode}} in a
> tree (e.g. inside {{Filter}}, {{Project}} and {{Join}}).
> I don't yet know whether, or how, rules might support 3-valued boolean logic
> ({{RexUnknownAs}}). For example, a rule that simplifies "x = x" to "TRUE" is
> valid in an "unknownAsFalse" context (e.g. as top-level of {{Filter}}
> condition), but not in an "unknownAsUnknown" context (e.g. in {{Project}}
> expression).
> This case is related to CALCITE-3470 (making relational and row-expression
> rules more similar, as in CockroachDB), but would deliver an API rather than
> a textual DSL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4559) Create 'interface RexRule', a modular rewrite for row-expressions
[
https://issues.apache.org/jira/browse/CALCITE-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17324151#comment-17324151
]
Danny Chen commented on CALCITE-4559:
-
Thanks [~julianhyde] for this fantastic feature, i believe this would be
another big move-forward for the rex optimization.
I looked into the PR overall and it generally looks good, just some confusion
about some interfaces of {{RexRule}}:
- There seems some overlap between {{RexRule.OperandBuilder#isLiteral}} and
{{RexRule.OperandBuilder#ofKind}}, and {{RexRule.OperandBuilder#ofKind}} and
{{RexRule.OperandBuilder#callTo}}, because the {{RexKind.LITERAL}} also
indicates a literal operand, and a RexKind can also indicates a {{RexCall}},
which brings confusion.
- {{RexRule.Done}}, the name {{Done}} is confusing too, can we have more
specific name instead ?
- Is {{OperandDetailBuilder.oneInput}} really necessary ?
> Create 'interface RexRule', a modular rewrite for row-expressions
> -
>
> Key: CALCITE-4559
> URL: https://issues.apache.org/jira/browse/CALCITE-4559
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> We propose to add {{class RexRule}}, a rewrite rule for row-expressions
> ({{class RexNode}}).
> {{class RexRule}} is analogous to how {{class RelRule}} (and the older
> {{class RelOptRule}}) operates on relational expressions ({{interface
> RelNode}}). Also, {{class RexRuleProgram}} is analogous to {{HepProgram}} and
> {{VolcanoPlanner}} (it indexes rules so that we do not have to try every rule
> against every part of the expression). And a rule describes which operands it
> matches using {{RexRule.describe(RexRule.OperandBuilder)}}, similar to
> calling {{RelRule.Config.operandSupplier().apply()}}.
> The advantages of {{RexRule}} are similar to {{RelRule}}: rules can be
> defined in a modular way, can be documented and tested individually, and can
> be enabled individually.
> The rules could be applied in various ways. {{RelBuilder.Config}} could
> contain a {{RexRuleProgram}} that would be applied every time an expression
> is simplified by a {{RelBuilder}}. There could also be a sub-class of
> {{interface RelShuttle}} that applies the rules to every {{RexNode}} in a
> tree (e.g. inside {{Filter}}, {{Project}} and {{Join}}).
> I don't yet know whether, or how, rules might support 3-valued boolean logic
> ({{RexUnknownAs}}). For example, a rule that simplifies "x = x" to "TRUE" is
> valid in an "unknownAsFalse" context (e.g. as top-level of {{Filter}}
> condition), but not in an "unknownAsUnknown" context (e.g. in {{Project}}
> expression).
> This case is related to CALCITE-3470 (making relational and row-expression
> rules more similar, as in CockroachDB), but would deliver an API rather than
> a textual DSL.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4565) UpperBound and lowerBound are silently re-written incorrectly during sql to rel conversion
[
https://issues.apache.org/jira/browse/CALCITE-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen updated CALCITE-4565:
Description:
In SqlToRelConverter.convertover there is a code snippet:
{code:java}
} else if (orderList.size() == 0) {
// Without ORDER BY, there must be no bracketing.
sqlLowerBound = SqlWindow.createUnboundedPreceding(SqlParserPos.ZERO);
sqlUpperBound = SqlWindow.createUnboundedFollowing(SqlParserPos.ZERO);
}
{code}
The SqlToRelConverter reset the lower/upper bounds silently when there is no
ORDER BY.
While i used the SQL below to check the behavior:
{code:sql}
create table t(
a int,
b int
);
insert into t values(1, 2);
insert into t values(3, 4);
insert into t values(5, 6);
insert into t values(7, 8);
insert into t values(9, 10);
insert into t values(11, 12);
insert into t values(13, 14);
SELECT count(1) over (rows between 2 preceding and 1 preceding) from T;
- PostgreSQL 9.6 returns the result as:
- 0
- 1
- 2
- 2
- 2
- 2
- 2
- While the Oracle throws exception:
- ORA-30485: missing ORDER BY expression in the window specification
{code}
So what is the correct behavior here ? Overall rewriting the bounds seem
different with all the other sql engines and it returns the wrong result always.
was:
In SqlToRelConverter.convertover there is a code snippet:
{code:java}
} else if (orderList.size() == 0) {
// Without ORDER BY, there must be no bracketing.
sqlLowerBound = SqlWindow.createUnboundedPreceding(SqlParserPos.ZERO);
sqlUpperBound = SqlWindow.createUnboundedFollowing(SqlParserPos.ZERO);
}
{code}
The SqlToRelConverter reset the lower/upper bounds silently when there is no
ORDER BY.
While i used the SQL below to check the behavior:
{code:sql}
create table t(
a int,
b int
);
insert into t values(1, 2);
insert into t values(3, 4);
insert into t values(5, 6);
insert into t values(7, 8);
insert into t values(9, 10);
insert into t values(11, 12);
insert into t values(13, 14);
SELECT count(1) over (rows between 2 preceding and 1 preceding) from T;
PostgreSQL 9.6 returns the result as:
0
1
2
2
2
2
2
While the Oracle throws exception:
ORA-30485: missing ORDER BY expression in the window specification
{code}
So what is the correct behavior here ? Overall rewriting the bounds seem
different with all the other sql engines and it returns the wrong result always.
> UpperBound and lowerBound are silently re-written incorrectly during sql to
> rel conversion
> --
>
> Key: CALCITE-4565
> URL: https://issues.apache.org/jira/browse/CALCITE-4565
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: next
>Reporter: Danny Chen
>Priority: Major
>
> In SqlToRelConverter.convertover there is a code snippet:
> {code:java}
> } else if (orderList.size() == 0) {
> // Without ORDER BY, there must be no bracketing.
> sqlLowerBound = SqlWindow.createUnboundedPreceding(SqlParserPos.ZERO);
> sqlUpperBound = SqlWindow.createUnboundedFollowing(SqlParserPos.ZERO);
> }
> {code}
> The SqlToRelConverter reset the lower/upper bounds silently when there is no
> ORDER BY.
> While i used the SQL below to check the behavior:
> {code:sql}
> create table t(
> a int,
> b int
> );
> insert into t values(1, 2);
> insert into t values(3, 4);
> insert into t values(5, 6);
> insert into t values(7, 8);
> insert into t values(9, 10);
> insert into t values(11, 12);
> insert into t values(13, 14);
> SELECT count(1) over (rows between 2 preceding and 1 preceding) from T;
> - PostgreSQL 9.6 returns the result as:
> - 0
> - 1
> - 2
> - 2
> - 2
> - 2
> - 2
> - While the Oracle throws exception:
> - ORA-30485: missing ORDER BY expression in the window specification
> {code}
> So what is the correct behavior here ? Overall rewriting the bounds seem
> different with all the other sql engines and it returns the wrong result
> always.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3877) In RexWindow, make fields upperBound and lowerBound not-nullable
[
https://issues.apache.org/jira/browse/CALCITE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315370#comment-17315370
]
Danny Chen commented on CALCITE-3877:
-
Created in CALCITE-4565.
> In RexWindow, make fields upperBound and lowerBound not-nullable
>
>
> Key: CALCITE-3877
> URL: https://issues.apache.org/jira/browse/CALCITE-3877
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.23.0
>
>
> Null lowerBound/upperBond in RexWindow causes NPE in RexShuttle. Here's a
> test that can be dropped into RexShuttleTest.java:
> {code:java}
> @Test public void handlesNullBoundsInRexWindow() {
> final RelBuilder builder =
> RelBuilder.create(RelBuilderTest.config().build());
> final RexNode over = builder.getRexBuilder().makeOver(
> builder.getTypeFactory().createSqlType(SqlTypeName.BIGINT),
> SqlStdOperatorTable.ROW_NUMBER,
> ImmutableList.of(),
> ImmutableList.of(),
> ImmutableList.of(),
> null,
> null,
> true,
> true,
> true,
> true,
>true
> );
> assertThat(over.accept(new RexShuttle()), is(over));
> }
> {code}
> That will raise an NPE. Fix is to handle NULLs when doing the child accept on
> the RexWindowBound[s] in RexShuttle.visitWindow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4565) UpperBound and lowerBound are silently re-written incorrectly during sql to rel conversion
[
https://issues.apache.org/jira/browse/CALCITE-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen updated CALCITE-4565:
Description:
In SqlToRelConverter.convertover there is a code snippet:
{code:java}
} else if (orderList.size() == 0) {
// Without ORDER BY, there must be no bracketing.
sqlLowerBound = SqlWindow.createUnboundedPreceding(SqlParserPos.ZERO);
sqlUpperBound = SqlWindow.createUnboundedFollowing(SqlParserPos.ZERO);
}
{code}
The SqlToRelConverter reset the lower/upper bounds silently when there is no
ORDER BY.
While i used the SQL below to check the behavior:
{code:sql}
create table t(
a int,
b int
);
insert into t values(1, 2);
insert into t values(3, 4);
insert into t values(5, 6);
insert into t values(7, 8);
insert into t values(9, 10);
insert into t values(11, 12);
insert into t values(13, 14);
SELECT count(1) over (rows between 2 preceding and 1 preceding) from T;
-- PostgreSQL 9.6 returns the result as:
-- 0
-- 1
-- 2
-- 2
-- 2
-- 2
-- 2
-- While the Oracle throws exception:
-- ORA-30485: missing ORDER BY expression in the window specification
{code}
So what is the correct behavior here ? Overall rewriting the bounds seem
different with all the other sql engines and it returns the wrong result always.
was:
In SqlToRelConverter.convertover there is a code snippet:
{code:java}
} else if (orderList.size() == 0) {
// Without ORDER BY, there must be no bracketing.
sqlLowerBound = SqlWindow.createUnboundedPreceding(SqlParserPos.ZERO);
sqlUpperBound = SqlWindow.createUnboundedFollowing(SqlParserPos.ZERO);
}
{code}
The SqlToRelConverter reset the lower/upper bounds silently when there is no
ORDER BY.
While i used the SQL below to check the behavior:
{code:sql}
create table t(
a int,
b int
);
insert into t values(1, 2);
insert into t values(3, 4);
insert into t values(5, 6);
insert into t values(7, 8);
insert into t values(9, 10);
insert into t values(11, 12);
insert into t values(13, 14);
SELECT count(1) over (rows between 2 preceding and 1 preceding) from T;
- PostgreSQL 9.6 returns the result as:
- 0
- 1
- 2
- 2
- 2
- 2
- 2
- While the Oracle throws exception:
- ORA-30485: missing ORDER BY expression in the window specification
{code}
So what is the correct behavior here ? Overall rewriting the bounds seem
different with all the other sql engines and it returns the wrong result always.
> UpperBound and lowerBound are silently re-written incorrectly during sql to
> rel conversion
> --
>
> Key: CALCITE-4565
> URL: https://issues.apache.org/jira/browse/CALCITE-4565
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: next
>Reporter: Danny Chen
>Priority: Major
>
> In SqlToRelConverter.convertover there is a code snippet:
> {code:java}
> } else if (orderList.size() == 0) {
> // Without ORDER BY, there must be no bracketing.
> sqlLowerBound = SqlWindow.createUnboundedPreceding(SqlParserPos.ZERO);
> sqlUpperBound = SqlWindow.createUnboundedFollowing(SqlParserPos.ZERO);
> }
> {code}
> The SqlToRelConverter reset the lower/upper bounds silently when there is no
> ORDER BY.
> While i used the SQL below to check the behavior:
> {code:sql}
> create table t(
> a int,
> b int
> );
> insert into t values(1, 2);
> insert into t values(3, 4);
> insert into t values(5, 6);
> insert into t values(7, 8);
> insert into t values(9, 10);
> insert into t values(11, 12);
> insert into t values(13, 14);
> SELECT count(1) over (rows between 2 preceding and 1 preceding) from T;
> -- PostgreSQL 9.6 returns the result as:
> -- 0
> -- 1
> -- 2
> -- 2
> -- 2
> -- 2
> -- 2
> -- While the Oracle throws exception:
> -- ORA-30485: missing ORDER BY expression in the window specification
> {code}
> So what is the correct behavior here ? Overall rewriting the bounds seem
> different with all the other sql engines and it returns the wrong result
> always.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4565) UpperBound and lowerBound are silently re-written incorrectly during sql to rel conversion
[
https://issues.apache.org/jira/browse/CALCITE-4565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen updated CALCITE-4565:
Description:
In SqlToRelConverter.convertover there is a code snippet:
{code:java}
} else if (orderList.size() == 0) {
// Without ORDER BY, there must be no bracketing.
sqlLowerBound = SqlWindow.createUnboundedPreceding(SqlParserPos.ZERO);
sqlUpperBound = SqlWindow.createUnboundedFollowing(SqlParserPos.ZERO);
}
{code}
The SqlToRelConverter reset the lower/upper bounds silently when there is no
ORDER BY.
While i used the SQL below to check the behavior:
{code:sql}
create table t(
a int,
b int
);
insert into t values(1, 2);
insert into t values(3, 4);
insert into t values(5, 6);
insert into t values(7, 8);
insert into t values(9, 10);
insert into t values(11, 12);
insert into t values(13, 14);
SELECT count(1) over (rows between 2 preceding and 1 preceding) from T;
PostgreSQL 9.6 returns the result as:
0
1
2
2
2
2
2
While the Oracle throws exception:
ORA-30485: missing ORDER BY expression in the window specification
{code}
So what is the correct behavior here ? Overall rewriting the bounds seem
different with all the other sql engines and it returns the wrong result always.
> UpperBound and lowerBound are silently re-written incorrectly during sql to
> rel conversion
> --
>
> Key: CALCITE-4565
> URL: https://issues.apache.org/jira/browse/CALCITE-4565
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: next
>Reporter: Danny Chen
>Priority: Major
>
> In SqlToRelConverter.convertover there is a code snippet:
> {code:java}
> } else if (orderList.size() == 0) {
> // Without ORDER BY, there must be no bracketing.
> sqlLowerBound = SqlWindow.createUnboundedPreceding(SqlParserPos.ZERO);
> sqlUpperBound = SqlWindow.createUnboundedFollowing(SqlParserPos.ZERO);
> }
> {code}
> The SqlToRelConverter reset the lower/upper bounds silently when there is no
> ORDER BY.
> While i used the SQL below to check the behavior:
> {code:sql}
> create table t(
> a int,
> b int
> );
> insert into t values(1, 2);
> insert into t values(3, 4);
> insert into t values(5, 6);
> insert into t values(7, 8);
> insert into t values(9, 10);
> insert into t values(11, 12);
> insert into t values(13, 14);
> SELECT count(1) over (rows between 2 preceding and 1 preceding) from T;
> PostgreSQL 9.6 returns the result as:
> 0
> 1
> 2
> 2
> 2
> 2
> 2
> While the Oracle throws exception:
> ORA-30485: missing ORDER BY expression in the window specification
> {code}
> So what is the correct behavior here ? Overall rewriting the bounds seem
> different with all the other sql engines and it returns the wrong result
> always.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4565) UpperBound and lowerBound are silently re-written incorrectly during sql to rel conversion
Danny Chen created CALCITE-4565: --- Summary: UpperBound and lowerBound are silently re-written incorrectly during sql to rel conversion Key: CALCITE-4565 URL: https://issues.apache.org/jira/browse/CALCITE-4565 Project: Calcite Issue Type: Bug Components: core Affects Versions: next Reporter: Danny Chen -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3877) In RexWindow, make fields upperBound and lowerBound not-nullable
[
https://issues.apache.org/jira/browse/CALCITE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308669#comment-17308669
]
Danny Chen commented on CALCITE-3877:
-
Agree with [~zabetak], the less silently changed grammars the less confusing.
> In RexWindow, make fields upperBound and lowerBound not-nullable
>
>
> Key: CALCITE-3877
> URL: https://issues.apache.org/jira/browse/CALCITE-3877
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.23.0
>
>
> Null lowerBound/upperBond in RexWindow causes NPE in RexShuttle. Here's a
> test that can be dropped into RexShuttleTest.java:
> {code:java}
> @Test public void handlesNullBoundsInRexWindow() {
> final RelBuilder builder =
> RelBuilder.create(RelBuilderTest.config().build());
> final RexNode over = builder.getRexBuilder().makeOver(
> builder.getTypeFactory().createSqlType(SqlTypeName.BIGINT),
> SqlStdOperatorTable.ROW_NUMBER,
> ImmutableList.of(),
> ImmutableList.of(),
> ImmutableList.of(),
> null,
> null,
> true,
> true,
> true,
> true,
>true
> );
> assertThat(over.accept(new RexShuttle()), is(over));
> }
> {code}
> That will raise an NPE. Fix is to handle NULLs when doing the child accept on
> the RexWindowBound[s] in RexShuttle.visitWindow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3877) In RexWindow, make fields upperBound and lowerBound not-nullable
[
https://issues.apache.org/jira/browse/CALCITE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17308312#comment-17308312
]
Danny Chen commented on CALCITE-3877:
-
Thanks [~julianhyde], then i guess you mean we should tweak the behavior based
on the {{SqlConformance}} which is different from the current code base.
In anyway, current codebase has the wrong behavior (silently changes the
bounds). Is my understanding right ?
> In RexWindow, make fields upperBound and lowerBound not-nullable
>
>
> Key: CALCITE-3877
> URL: https://issues.apache.org/jira/browse/CALCITE-3877
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.23.0
>
>
> Null lowerBound/upperBond in RexWindow causes NPE in RexShuttle. Here's a
> test that can be dropped into RexShuttleTest.java:
> {code:java}
> @Test public void handlesNullBoundsInRexWindow() {
> final RelBuilder builder =
> RelBuilder.create(RelBuilderTest.config().build());
> final RexNode over = builder.getRexBuilder().makeOver(
> builder.getTypeFactory().createSqlType(SqlTypeName.BIGINT),
> SqlStdOperatorTable.ROW_NUMBER,
> ImmutableList.of(),
> ImmutableList.of(),
> ImmutableList.of(),
> null,
> null,
> true,
> true,
> true,
> true,
>true
> );
> assertThat(over.accept(new RexShuttle()), is(over));
> }
> {code}
> That will raise an NPE. Fix is to handle NULLs when doing the child accept on
> the RexWindowBound[s] in RexShuttle.visitWindow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3877) In RexWindow, make fields upperBound and lowerBound not-nullable
[
https://issues.apache.org/jira/browse/CALCITE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307527#comment-17307527
]
Danny Chen commented on CALCITE-3877:
-
Oops, sorry, i run this one
{code:sql}
SELECT count(1) over (rows between 2 preceding and 1 preceding) from T;
{code}
> In RexWindow, make fields upperBound and lowerBound not-nullable
>
>
> Key: CALCITE-3877
> URL: https://issues.apache.org/jira/browse/CALCITE-3877
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.23.0
>
>
> Null lowerBound/upperBond in RexWindow causes NPE in RexShuttle. Here's a
> test that can be dropped into RexShuttleTest.java:
> {code:java}
> @Test public void handlesNullBoundsInRexWindow() {
> final RelBuilder builder =
> RelBuilder.create(RelBuilderTest.config().build());
> final RexNode over = builder.getRexBuilder().makeOver(
> builder.getTypeFactory().createSqlType(SqlTypeName.BIGINT),
> SqlStdOperatorTable.ROW_NUMBER,
> ImmutableList.of(),
> ImmutableList.of(),
> ImmutableList.of(),
> null,
> null,
> true,
> true,
> true,
> true,
>true
> );
> assertThat(over.accept(new RexShuttle()), is(over));
> }
> {code}
> That will raise an NPE. Fix is to handle NULLs when doing the child accept on
> the RexWindowBound[s] in RexShuttle.visitWindow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4545) Unparse a new function of FUNCTION_ID syntax will be quoted
[
https://issues.apache.org/jira/browse/CALCITE-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17307526#comment-17307526
]
Danny Chen commented on CALCITE-4545:
-
[~julianhyde] I changed that in CALCITE-2674.
> Unparse a new function of FUNCTION_ID syntax will be quoted
> ---
>
> Key: CALCITE-4545
> URL: https://issues.apache.org/jira/browse/CALCITE-4545
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jark Wu
>Priority: Major
> Fix For: 1.26.0, 1.27.0
>
>
> In Flink, we would like to introduce some new functions of FUNCTION_ID
> syntax, e.g. {{CURRENT_ROW_TIMESTAMP}}. However, when unparsing this new
> function, we will get the quoted string {{`CURRENT_ROW_TIMESTAMP`}} which
> can't be executed anymore, because Calcite think it is a column reference.
> The root cause of it is {{org.apache.calcite.sql.SqlIdentifier#unparse}}
> calls {{org.apache.calcite.sql.SqlUtil#unparseSqlIdentifierSyntax}} where it
> uses a static Calcite {{SqlStdOperatorTable.instance()}} instead of a
> user-defined operator table. Therefore, it thinks it's not a sql function and
> unparse it with quotes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3877) In RexWindow, make fields upperBound and lowerBound not-nullable
[
https://issues.apache.org/jira/browse/CALCITE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306904#comment-17306904
]
Danny Chen commented on CALCITE-3877:
-
Hi Julian ~
In {{SqlToRelConverter.convertover}} there is a code snippet:
{code:java}
} else if (orderList.size() == 0) {
// Without ORDER BY, there must be no bracketing.
sqlLowerBound = SqlWindow.createUnboundedPreceding(SqlParserPos.ZERO);
sqlUpperBound = SqlWindow.createUnboundedFollowing(SqlParserPos.ZERO);
}
{code}
The {{SqlToRelConverter}} reset the lower/upper bounds silently when there is
no ORDER BY.
While i used the SQL below to check the behavior:
{code:sql}
create table t(
a int,
b int
);
insert into t values(1, 2);
insert into t values(3, 4);
insert into t values(5, 6);
insert into t values(7, 8);
insert into t values(9, 10);
insert into t values(11, 12);
insert into t values(13, 14);
{code}
PostgreSQL 9.6 returns the result as:
{code:sql}
0
1
2
2
2
2
2
{code}
While the Oracle throws exception:
{noformat}ORA-30485: missing ORDER BY expression in the window
specification{noformat}
So what is the correct behavior here ? Overall rewriting the bounds seem
different with all the other sql engines and it returns the wrong result always.
> In RexWindow, make fields upperBound and lowerBound not-nullable
>
>
> Key: CALCITE-3877
> URL: https://issues.apache.org/jira/browse/CALCITE-3877
> Project: Calcite
> Issue Type: Bug
>Reporter: Steven Talbot
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.23.0
>
>
> Null lowerBound/upperBond in RexWindow causes NPE in RexShuttle. Here's a
> test that can be dropped into RexShuttleTest.java:
> {code:java}
> @Test public void handlesNullBoundsInRexWindow() {
> final RelBuilder builder =
> RelBuilder.create(RelBuilderTest.config().build());
> final RexNode over = builder.getRexBuilder().makeOver(
> builder.getTypeFactory().createSqlType(SqlTypeName.BIGINT),
> SqlStdOperatorTable.ROW_NUMBER,
> ImmutableList.of(),
> ImmutableList.of(),
> ImmutableList.of(),
> null,
> null,
> true,
> true,
> true,
> true,
>true
> );
> assertThat(over.accept(new RexShuttle()), is(over));
> }
> {code}
> That will raise an NPE. Fix is to handle NULLs when doing the child accept on
> the RexWindowBound[s] in RexShuttle.visitWindow.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4545) Unparse a new function of FUNCTION_ID syntax will be quoted
[
https://issues.apache.org/jira/browse/CALCITE-4545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17306859#comment-17306859
]
Danny Chen commented on CALCITE-4545:
-
For the old version parser before CALCITE-2282, the parser did can identifies
some builtin no-arg functions, but only for operators from
{{SqlStdOperatorTable}}.
When unparsing a {{SqlIdentifier}}, we can decide whether the {{SqlIdentifier}}
is simple and whether it is quoted in the original SQL statement, one way to
fix is that we never apply the quotes for a simple {{SqlIdentifier}} if it is
not quoted in the original SQL, because that may changes the semantics based on
the fact that a quoted {{SqlIdentifier}}
can never parse to a function.
> Unparse a new function of FUNCTION_ID syntax will be quoted
> ---
>
> Key: CALCITE-4545
> URL: https://issues.apache.org/jira/browse/CALCITE-4545
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jark Wu
>Priority: Major
> Fix For: 1.26.0, 1.27.0
>
>
> In Flink, we would like to introduce some new functions of FUNCTION_ID
> syntax, e.g. {{CURRENT_ROW_TIMESTAMP}}. However, when unparsing this new
> function, we will get the quoted string {{`CURRENT_ROW_TIMESTAMP`}} which
> can't be executed anymore, because Calcite think it is a column reference.
> The root cause of it is {{org.apache.calcite.sql.SqlIdentifier#unparse}}
> calls {{org.apache.calcite.sql.SqlUtil#unparseSqlIdentifierSyntax}} where it
> uses a static Calcite {{SqlStdOperatorTable.instance()}} instead of a
> user-defined operator table. Therefore, it thinks it's not a sql function and
> unparse it with quotes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4526) SqlSnapshot unparse lost the AS keyword when the table has alias
[ https://issues.apache.org/jira/browse/CALCITE-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17300020#comment-17300020 ] Danny Chen commented on CALCITE-4526: - Thanks for the reminder, Julian, force pushed via: https://github.com/apache/calcite/commit/39d477d96b90eca05e5af1cec0f8ae0617226b5d. > SqlSnapshot unparse lost the AS keyword when the table has alias > > > Key: CALCITE-4526 > URL: https://issues.apache.org/jira/browse/CALCITE-4526 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.26.0 >Reporter: jibiyr >Assignee: jibiyr >Priority: Blocker > Labels: pull-request-available > Fix For: next > > Time Spent: 2h 10m > Remaining Estimate: 0h > > hi,community. now calcite support SqlSnapshot. > when a sql like _*SELECT orders.order_id, products.pro_id, > products.product_name*_ > _*FROM default_catalog.default_database.orders AS orders*_ > _*LEFT JOIN default_catalog.default_database.products FOR SYSTEM_TIME AS OF > orders.proctime AS products ON orders.product_id = products.pro_id .*_ > > _*default_catalog.default_database.products FOR SYSTEM_TIME AS OF > orders.proctime AS products*_ parse to SqlSnapshot .however, when unparse. > it is _*default_catalog.default_database.products AS products FOR SYSTEM_TIME > AS OF orders.proctime.*_ which can not be parsed again. > > if we should consider this condition. > the same problem when I found in FLINK-19670. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4526) SqlSnapshot unparse lost the AS keyword when the table has alias
[ https://issues.apache.org/jira/browse/CALCITE-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen updated CALCITE-4526: Summary: SqlSnapshot unparse lost the AS keyword when the table has alias (was: Fixup the unparse's output of SqlSnapshot when the table has alias) > SqlSnapshot unparse lost the AS keyword when the table has alias > > > Key: CALCITE-4526 > URL: https://issues.apache.org/jira/browse/CALCITE-4526 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.26.0 >Reporter: jibiyr >Assignee: jibiyr >Priority: Blocker > Labels: pull-request-available > Fix For: next > > Time Spent: 2h 10m > Remaining Estimate: 0h > > hi,community. now calcite support SqlSnapshot. > when a sql like _*SELECT orders.order_id, products.pro_id, > products.product_name*_ > _*FROM default_catalog.default_database.orders AS orders*_ > _*LEFT JOIN default_catalog.default_database.products FOR SYSTEM_TIME AS OF > orders.proctime AS products ON orders.product_id = products.pro_id .*_ > > _*default_catalog.default_database.products FOR SYSTEM_TIME AS OF > orders.proctime AS products*_ parse to SqlSnapshot .however, when unparse. > it is _*default_catalog.default_database.products AS products FOR SYSTEM_TIME > AS OF orders.proctime.*_ which can not be parsed again. > > if we should consider this condition. > the same problem when I found in FLINK-19670. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4526) Fixup the unparse's output of SqlSnapshot when the table has alias
[ https://issues.apache.org/jira/browse/CALCITE-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen resolved CALCITE-4526. - Fix Version/s: next Resolution: Fixed Fixed in [75b9440|https://github.com/apache/calcite/commit/75b944067d3511fc60ed0b112f1ea66dd34c7b1b], thanks for the contribution, [~yr] ~ > Fixup the unparse's output of SqlSnapshot when the table has alias > -- > > Key: CALCITE-4526 > URL: https://issues.apache.org/jira/browse/CALCITE-4526 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.26.0 >Reporter: jibiyr >Assignee: jibiyr >Priority: Blocker > Labels: pull-request-available > Fix For: next > > Time Spent: 2h 10m > Remaining Estimate: 0h > > hi,community. now calcite support SqlSnapshot. > when a sql like _*SELECT orders.order_id, products.pro_id, > products.product_name*_ > _*FROM default_catalog.default_database.orders AS orders*_ > _*LEFT JOIN default_catalog.default_database.products FOR SYSTEM_TIME AS OF > orders.proctime AS products ON orders.product_id = products.pro_id .*_ > > _*default_catalog.default_database.products FOR SYSTEM_TIME AS OF > orders.proctime AS products*_ parse to SqlSnapshot .however, when unparse. > it is _*default_catalog.default_database.products AS products FOR SYSTEM_TIME > AS OF orders.proctime.*_ which can not be parsed again. > > if we should consider this condition. > the same problem when I found in FLINK-19670. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4526) Fixup the unparse's output of SqlSnapshot when the table has alias
[ https://issues.apache.org/jira/browse/CALCITE-4526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen updated CALCITE-4526: Summary: Fixup the unparse's output of SqlSnapshot when the table has alias (was: SqlSnapshot unparse problem when tablRef is As-SqlBasicCall) > Fixup the unparse's output of SqlSnapshot when the table has alias > -- > > Key: CALCITE-4526 > URL: https://issues.apache.org/jira/browse/CALCITE-4526 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.26.0 >Reporter: jibiyr >Assignee: jibiyr >Priority: Blocker > Labels: pull-request-available > Time Spent: 2h 10m > Remaining Estimate: 0h > > hi,community. now calcite support SqlSnapshot. > when a sql like _*SELECT orders.order_id, products.pro_id, > products.product_name*_ > _*FROM default_catalog.default_database.orders AS orders*_ > _*LEFT JOIN default_catalog.default_database.products FOR SYSTEM_TIME AS OF > orders.proctime AS products ON orders.product_id = products.pro_id .*_ > > _*default_catalog.default_database.products FOR SYSTEM_TIME AS OF > orders.proctime AS products*_ parse to SqlSnapshot .however, when unparse. > it is _*default_catalog.default_database.products AS products FOR SYSTEM_TIME > AS OF orders.proctime.*_ which can not be parsed again. > > if we should consider this condition. > the same problem when I found in FLINK-19670. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4521) Support User Defined Table-valued Function
[
https://issues.apache.org/jira/browse/CALCITE-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17299339#comment-17299339
]
Danny Chen commented on CALCITE-4521:
-
I guess this issue is not about UDTF but UDTVF, which is a little different,
the latter can pass in table name as parameters and has solid schema.
> Support User Defined Table-valued Function
> --
>
> Key: CALCITE-4521
> URL: https://issues.apache.org/jira/browse/CALCITE-4521
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: herodu
>Priority: Major
>
> It already support TUMBLE/HOP/SESSION windowing table-valued function in
> current version. But in fact, the table-valued function is not just the
> current features, and we want to support user defined table-valued function,
> just like the following query:
> {code:java}
> select * from table(UDTVF(table Shipments))
> {code}
> or
> {code:java}
> select * from table(UDTVF(select * from Shipments)){code}
> The input parameters of 'UDTVF' is the output rowtype of the inner subquery,
> and the output of 'UDTVF' is defined by users, just like:
> {code:java}
> final TableValuedFunction tableValuedFunction =
> (RelDataTypeFactory typeFactory) -> typeFactory.builder()
> .add("in1", SqlTypeName.INTEGER)
> .add("in2", SqlTypeName.VARCHAR)
> .build();
> {code}
>
> And the expected output logic plan like:
> {code:java}
> LogicalProject(in1=[$0], in2=[$1])
> LogicalTableFunctionScan(invocation=[UDTVF($0, $1)],
> rowType=[RecordType(INTEGER in1,VARCHAR in2)])
> LogicalProject(ORDERID=[$0], ROWTIME=[$1])
> LogicalTableScan(table=[[CATALOG, SALES, SHIPMENTS]])
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4521) Support User Defined Table-valued Function
[
https://issues.apache.org/jira/browse/CALCITE-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17297062#comment-17297062
]
Danny Chen commented on CALCITE-4521:
-
Thanks for the work, Julian ~
> Support User Defined Table-valued Function
> --
>
> Key: CALCITE-4521
> URL: https://issues.apache.org/jira/browse/CALCITE-4521
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: herodu
>Priority: Major
>
> It already support TUMBLE/HOP/SESSION windowing table-valued function in
> current version. But in fact, the table-valued function is not just the
> current features, and we want to support user defined table-valued function,
> just like the following query:
> {code:java}
> select * from table(UDTVF(table Shipments))
> {code}
> or
> {code:java}
> select * from table(UDTVF(select * from Shipments)){code}
> The input parameters of 'UDTVF' is the output rowtype of the inner subquery,
> and the output of 'UDTVF' is defined by users, just like:
> {code:java}
> final TableValuedFunction tableValuedFunction =
> (RelDataTypeFactory typeFactory) -> typeFactory.builder()
> .add("in1", SqlTypeName.INTEGER)
> .add("in2", SqlTypeName.VARCHAR)
> .build();
> {code}
>
> And the expected output logic plan like:
> {code:java}
> LogicalProject(in1=[$0], in2=[$1])
> LogicalTableFunctionScan(invocation=[UDTVF($0, $1)],
> rowType=[RecordType(INTEGER in1,VARCHAR in2)])
> LogicalProject(ORDERID=[$0], ROWTIME=[$1])
> LogicalTableScan(table=[[CATALOG, SALES, SHIPMENTS]])
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4521) Support User Defined Table-valued Function
[
https://issues.apache.org/jira/browse/CALCITE-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17295042#comment-17295042
]
Danny Chen commented on CALCITE-4521:
-
Reasonable, actually the SQL 2017 already defines some builtin TVFs(such as the
CSVReader), maybe that is a good start to have a definition in Calcite first.
> Support User Defined Table-valued Function
> --
>
> Key: CALCITE-4521
> URL: https://issues.apache.org/jira/browse/CALCITE-4521
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: herodu
>Priority: Major
>
> It already support TUMBLE/HOP/SESSION windowing table-valued function in
> current version. But in fact, the table-valued function is not just the
> current features, and we want to support user defined table-valued function,
> just like the following query:
> {code:java}
> select * from table(UDTVF(table Shipments))
> {code}
> or
> {code:java}
> select * from table(UDTVF(select * from Shipments)){code}
> The input parameters of 'UDTVF' is the output rowtype of the inner subquery,
> and the output of 'UDTVF' is defined by users, just like:
> {code:java}
> final TableValuedFunction tableValuedFunction =
> (RelDataTypeFactory typeFactory) -> typeFactory.builder()
> .add("in1", SqlTypeName.INTEGER)
> .add("in2", SqlTypeName.VARCHAR)
> .build();
> {code}
>
> And the expected output logic plan like:
> {code:java}
> LogicalProject(in1=[$0], in2=[$1])
> LogicalTableFunctionScan(invocation=[UDTVF($0, $1)],
> rowType=[RecordType(INTEGER in1,VARCHAR in2)])
> LogicalProject(ORDERID=[$0], ROWTIME=[$1])
> LogicalTableScan(table=[[CATALOG, SALES, SHIPMENTS]])
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4514) [CALCITE-4514] Fine tune the merge order of two RelSets
[ https://issues.apache.org/jira/browse/CALCITE-4514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292627#comment-17292627 ] Danny Chen commented on CALCITE-4514: - The comment in the code should also be renamed, E.G. "set" -> "set1". > [CALCITE-4514] Fine tune the merge order of two RelSets > --- > > Key: CALCITE-4514 > URL: https://issues.apache.org/jira/browse/CALCITE-4514 > Project: Calcite > Issue Type: Improvement >Reporter: Botong Huang >Priority: Minor > Labels: pull-request-available > Fix For: 1.27.0 > > Time Spent: 40m > Remaining Estimate: 0h > > When merging two relsets, we have two preferences: > 1. Merge parent relset into child relset > 2. Merge newer relset into older relset > Currently, when the two relsets are parent set of each other, we randomly > pick a merge order without checking the second condition above. For > performance reasons, we should, to avoid unnecessary churn. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-613) Implicitly convert character values in comparisons
[ https://issues.apache.org/jira/browse/CALCITE-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17292596#comment-17292596 ] Danny Chen commented on CALCITE-613: Yes, this is a common case that implicit type coercion should cover. > Implicitly convert character values in comparisons > -- > > Key: CALCITE-613 > URL: https://issues.apache.org/jira/browse/CALCITE-613 > Project: Calcite > Issue Type: Bug >Reporter: Sean Hsuan-Yi Chu >Assignee: Julian Hyde >Priority: Major > Fix For: 1.2.0-incubating > > > In relational DB such as Postgres, this query works fine. > "select ... from ... where column (INT type) between '10' and '11'" > Calcite blocks this query early by the fact that data types "char" & > "integer" are not directly compatible. However, this is very common for > people to filter columns with date types. For example, > "...where date between '1911-01-01' and '1911-01-02' " > To relax this type check when comparing with literals can help improve > usability. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4507) 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
[
https://issues.apache.org/jira/browse/CALCITE-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289050#comment-17289050
]
Danny Chen commented on CALCITE-4507:
-
Thanks for the explanation, i agree that CALCITE-4446 can cover this case.
> 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
> -
>
> Key: CALCITE-4507
> URL: https://issues.apache.org/jira/browse/CALCITE-4507
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
>
> SQL statements:
> {code:sql}
> a = 0 or a is null -- returns true when a is null
> a in (0, null) -- returns null when a is null
> {code}
> have different semantics when {{a}} is null, we should not represent it as a
> sarg after {{RexSimplify}},
> check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInOr() {
> or(
> gt(vInt(), literal(0)),
> isNull(vInt())),
> ">(?0.int0, 0)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4507) 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
[
https://issues.apache.org/jira/browse/CALCITE-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288906#comment-17288906
]
Danny Chen edited comment on CALCITE-4507 at 2/23/21, 7:20 AM:
---
For the example in CALCITE-4446:
{{Sarg(10, 20, UNKNOWN AS UNKNOWN): x IN (10, 20) → UNKNOWN}}
then, what does {{x IN (10, null)}} return if x is null ? In mysql, it returns
null (which i guess comes form an {{UNKNOWN}}). So mysql assumes {{x IN (10,
null)}} returns {{UNKNOWN}} when x is null.
The question here is that {{IN}} compares the values using *EQUALS*, it is
different with *x is NULL* statement, so i think this case is a little
different, which is not a duplicate of CALCITE-4446.
{{x = 0 or x is null}} can never be rewritten to {{x IN(0, null)}} no matter
what {{UNKNOWN AS}} value we have.
was (Author: danny0405):
For the example in CALCITE-4446:
{{Sarg(10, 20, UNKNOWN AS UNKNOWN): x IN (10, 20) → UNKNOWN}}
then, what does {{x IN (10, null)}} returns if x is null ? In mysql, it returns
null (which i guess comes form an {{UNKNOWN}}). So mysql assumes {{x IN (10,
null)}} returns {{UNKNOWN}} when x is null.
The question here is that {{IN}} compares the values using *EQUALS*, it is
different with *x is NULL* statement, so i think this case is a little
different, which is not a duplicate of CALCITE-4446.
{{x = 0 or x is null}} can never be written to {{x IN(0, null)}} no matter what
{{UNKNOWN AS}} value we have.
> 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
> -
>
> Key: CALCITE-4507
> URL: https://issues.apache.org/jira/browse/CALCITE-4507
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
>
> SQL statements:
> {code:sql}
> a = 0 or a is null -- returns true when a is null
> a in (0, null) -- returns null when a is null
> {code}
> have different semantics when {{a}} is null, we should not represent it as a
> sarg after {{RexSimplify}},
> check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInOr() {
> or(
> gt(vInt(), literal(0)),
> isNull(vInt())),
> ">(?0.int0, 0)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4507) 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
[
https://issues.apache.org/jira/browse/CALCITE-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17288906#comment-17288906
]
Danny Chen commented on CALCITE-4507:
-
For the example in CALCITE-4446:
{{Sarg(10, 20, UNKNOWN AS UNKNOWN): x IN (10, 20) → UNKNOWN}}
then, what does {{x IN (10, null)}} returns if x is null ? In mysql, it returns
null (which i guess comes form an {{UNKNOWN}}). So mysql assumes {{x IN (10,
null)}} returns {{UNKNOWN}} when x is null.
The question here is that {{IN}} compares the values using *EQUALS*, it is
different with *x is NULL* statement, so i think this case is a little
different, which is not a duplicate of CALCITE-4446.
{{x = 0 or x is null}} can never be written to {{x IN(0, null)}} no matter what
{{UNKNOWN AS}} value we have.
> 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
> -
>
> Key: CALCITE-4507
> URL: https://issues.apache.org/jira/browse/CALCITE-4507
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
>
> SQL statements:
> {code:sql}
> a = 0 or a is null -- returns true when a is null
> a in (0, null) -- returns null when a is null
> {code}
> have different semantics when {{a}} is null, we should not represent it as a
> sarg after {{RexSimplify}},
> check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInOr() {
> or(
> gt(vInt(), literal(0)),
> isNull(vInt())),
> ">(?0.int0, 0)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4507) 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
[
https://issues.apache.org/jira/browse/CALCITE-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen updated CALCITE-4507:
Description:
SQL statements:
{code:sql}
a = 0 or a is null -- returns true when a is null
a in (0, null) -- returns null when a is null
{code}
have different semantics when {{a}} is null, we should not represent it as a
sarg after {{RexSimplify}},
check this test in {{RexProgramTest}}:
{code:java}
@Test void testSimplifyInOr() {
or(
gt(vInt(), literal(0)),
isNull(vInt())),
">(?0.int0, 0)");
}
{code}
> 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
> -
>
> Key: CALCITE-4507
> URL: https://issues.apache.org/jira/browse/CALCITE-4507
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0, 1.27.0
>Reporter: Danny Chen
>Priority: Major
>
> SQL statements:
> {code:sql}
> a = 0 or a is null -- returns true when a is null
> a in (0, null) -- returns null when a is null
> {code}
> have different semantics when {{a}} is null, we should not represent it as a
> sarg after {{RexSimplify}},
> check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInOr() {
> or(
> gt(vInt(), literal(0)),
> isNull(vInt())),
> ">(?0.int0, 0)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4507) 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
[ https://issues.apache.org/jira/browse/CALCITE-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen updated CALCITE-4507: Component/s: core > 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)' > - > > Key: CALCITE-4507 > URL: https://issues.apache.org/jira/browse/CALCITE-4507 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.26.0, 1.27.0 >Reporter: Danny Chen >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4507) 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
Danny Chen created CALCITE-4507: --- Summary: 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)' Key: CALCITE-4507 URL: https://issues.apache.org/jira/browse/CALCITE-4507 Project: Calcite Issue Type: Bug Reporter: Danny Chen -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4507) 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)'
[ https://issues.apache.org/jira/browse/CALCITE-4507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen updated CALCITE-4507: Affects Version/s: 1.27.0 1.26.0 > 'a = 0 or a is null' should not be rewrite to a sarg 'a in (0, null)' > - > > Key: CALCITE-4507 > URL: https://issues.apache.org/jira/browse/CALCITE-4507 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.26.0, 1.27.0 >Reporter: Danny Chen >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-4265) Improve error message when CAST to unknown type
[
https://issues.apache.org/jira/browse/CALCITE-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4265.
-
Fix Version/s: next
Assignee: Danny Chen
Resolution: Fixed
Fixed in
[207bc8a|https://github.com/apache/calcite/commit/207bc8a0d731fa40e84309dfea3f8189b383e117],
thanks for the PR, [~lllouiskuang] ~
> Improve error message when CAST to unknown type
> ---
>
> Key: CALCITE-4265
> URL: https://issues.apache.org/jira/browse/CALCITE-4265
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: next
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Improve error message when {{CAST}} to unknown type. If you add the following
> test case to {{RelToSqlConverterTest}}, you get an
> {{UnsupportedOperationException}} during validation due to the unknown
> datatype {{SIGNED}}:
> {code}
> @Test void testSelectFromUnionGrouping() {
> String query = "SELECT CASE WHEN \"t3\".\"groupingVal\" IN (0, 1) THEN
> \"t\".\"fname\" ELSE NULL END AS name, "
> + "CASE WHEN \"t3\".\"groupingVal\" = 0 THEN \"t\".\"birthdate\" ELSE
> NULL END AS birthdate, AVG(\"t\".\"__f2\") AS "
> + "\"__f2\", CAST(CASE WHEN \"t3\".\"groupingVal\" = 0 THEN 0 ELSE 1 END
> AS SIGNED) AS \"__f3\", CAST(CASE WHEN"
> + " \"t3\".\"groupingVal\" IN (0, 1) THEN 0 ELSE 1 END + CASE WHEN
> \"t3\".\"groupingVal\" = 0 THEN 0 ELSE 2 "
> + "END AS SIGNED) AS \"__f4\"\n"
> + "FROM (SELECT \"fname\", \"birthdate\", \"total_children\" + 2 AS
> \"__f2\"\n"
> + "FROM \"foodmart\".\"customer\") AS \"t\",\n"
> + "(SELECT 0 AS \"groupingVal\"\n"
> + "UNION ALL\n"
> + "SELECT 1 AS \"groupingVal\"\n"
> + "UNION ALL\n"
> + "SELECT 2 AS \"groupingVal\") AS \"t3\"\n"
> + "GROUP BY CASE WHEN \"t3\".\"groupingVal\" IN (0, 1) THEN
> \"t\".\"fname\" ELSE NULL END, CASE WHEN \"t3\""
> + ".\"groupingVal\" = 0 THEN \"t\".\"birthdate\" ELSE NULL END,
> \"t3\".\"groupingVal\"";
> sql(query).ok("--");
> }{code} throws
> {noformat}
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlIdentifier: SIGNED
> at org.apache.calcite.util.Util.needToImplement(Util.java:1074)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.getValidatedNodeType(SqlValidatorImpl.java:1655)
> at
> org.apache.calcite.sql.SqlUserDefinedTypeNameSpec.deriveType(SqlUserDefinedTypeNameSpec.java:49)
> at
> org.apache.calcite.sql.SqlDataTypeSpec.deriveType(SqlDataTypeSpec.java:222)
> at
> org.apache.calcite.sql.SqlDataTypeSpec.deriveType(SqlDataTypeSpec.java:209)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5868)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5753)
> at
> org.apache.calcite.sql.SqlDataTypeSpec.accept(SqlDataTypeSpec.java:186)
> {noformat}
> If you change {{SIGNED}} to {{INTEGER}} the exception goes away.
> Clearly this test case is not minimal. There could probably be a 1 line test
> case for {{SqlValidatorTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4479) "vFloat in (1.0, 2.0)" throws UnsupportedOperationException
[
https://issues.apache.org/jira/browse/CALCITE-4479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4479.
-
Resolution: Fixed
Fixed in
[039fe49|https://github.com/apache/calcite/commit/039fe493e195416ee40c93b720f304ac9fc3c8c8]
!
> "vFloat in (1.0, 2.0)" throws UnsupportedOperationException
> ---
>
> Key: CALCITE-4479
> URL: https://issues.apache.org/jira/browse/CALCITE-4479
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Check this test in {{RexBuilderTest}}:
> {code:java}
> @Test void testMakeIn() {
> final RelDataTypeFactory typeFactory =
> new SqlTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
> final RexBuilder rexBuilder = new RexBuilder(typeFactory);
> final RelDataType floatType =
> typeFactory.createSqlType(SqlTypeName.FLOAT);
> RexNode left = rexBuilder.makeInputRef(floatType, 0);
> final RexNode literal1 = rexBuilder.makeLiteral(1.0f, floatType);
> final RexNode literal2 = rexBuilder.makeLiteral(2.0f, floatType);
> RexNode inCall = rexBuilder.makeIn(left, ImmutableList.of(literal1,
> literal2));
> assertThat(inCall.getKind(), is(SqlKind.SEARCH));
> }
> {code}
> The stacktrace is:
> {noformat}
> class org.apache.calcite.sql.type.SqlTypeName: FLOAT
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.type.SqlTypeName: FLOAT
> at org.apache.calcite.util.Util.needToImplement(Util.java:1085)
> at org.apache.calcite.rex.RexLiteral.appendAsJava(RexLiteral.java:726)
> at org.apache.calcite.rex.RexLiteral.toJavaString(RexLiteral.java:427)
> at org.apache.calcite.rex.RexLiteral.computeDigest(RexLiteral.java:289)
> at org.apache.calcite.rex.RexLiteral.(RexLiteral.java:233)
> at org.apache.calcite.rex.RexLiteral.toLiteral(RexLiteral.java:762)
> at
> org.apache.calcite.rex.RexLiteral.lambda$printSarg$4(RexLiteral.java:733)
> at
> org.apache.calcite.util.RangeSets$Printer.singleton(RangeSets.java:409)
> at org.apache.calcite.util.RangeSets.forEach(RangeSets.java:249)
> at org.apache.calcite.util.Sarg.lambda$printTo$0(Sarg.java:119)
> at org.apache.calcite.linq4j.Ord.forEach(Ord.java:157)
> at org.apache.calcite.util.Sarg.printTo(Sarg.java:115)
> at org.apache.calcite.rex.RexLiteral.printSarg(RexLiteral.java:732)
> at
> org.apache.calcite.rex.RexLiteral.lambda$appendAsJava$1(RexLiteral.java:673)
> at org.apache.calcite.util.Util.asStringBuilder(Util.java:2525)
> at org.apache.calcite.rex.RexLiteral.appendAsJava(RexLiteral.java:672)
> at org.apache.calcite.rex.RexLiteral.toJavaString(RexLiteral.java:427)
> at org.apache.calcite.rex.RexLiteral.computeDigest(RexLiteral.java:289)
> at org.apache.calcite.rex.RexLiteral.(RexLiteral.java:233)
> at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:990)
> at
> org.apache.calcite.rex.RexBuilder.makeSearchArgumentLiteral(RexBuilder.java:1085)
> at org.apache.calcite.rex.RexBuilder.makeIn(RexBuilder.java:1335)
> at
> org.apache.calcite.rex.RexBuilderTest.testMakeIn(RexBuilderTest.java:621)
> {noformat}
> The root cause is that {{RexLiteral#strictTypeName}} has different type name
> strategies with what {{RexBuilder.makeLiteral}} follows, the best way to fix
> is to make the rules synced, but here i only give a simple fix because the
> code path only used for Sarg digest.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4479) "vFloat in (1.0, 2.0)" throws UnsupportedOperationException
Danny Chen created CALCITE-4479:
---
Summary: "vFloat in (1.0, 2.0)" throws
UnsupportedOperationException
Key: CALCITE-4479
URL: https://issues.apache.org/jira/browse/CALCITE-4479
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.26.0
Reporter: Danny Chen
Assignee: Danny Chen
Fix For: 1.27.0
Check this test in {{RexBuilderTest}}:
{code:java}
@Test void testMakeIn() {
final RelDataTypeFactory typeFactory =
new SqlTypeFactoryImpl(RelDataTypeSystem.DEFAULT);
final RexBuilder rexBuilder = new RexBuilder(typeFactory);
final RelDataType floatType = typeFactory.createSqlType(SqlTypeName.FLOAT);
RexNode left = rexBuilder.makeInputRef(floatType, 0);
final RexNode literal1 = rexBuilder.makeLiteral(1.0f, floatType);
final RexNode literal2 = rexBuilder.makeLiteral(2.0f, floatType);
RexNode inCall = rexBuilder.makeIn(left, ImmutableList.of(literal1,
literal2));
assertThat(inCall.getKind(), is(SqlKind.SEARCH));
}
{code}
The stacktrace is:
{noformat}
class org.apache.calcite.sql.type.SqlTypeName: FLOAT
java.lang.UnsupportedOperationException: class
org.apache.calcite.sql.type.SqlTypeName: FLOAT
at org.apache.calcite.util.Util.needToImplement(Util.java:1085)
at org.apache.calcite.rex.RexLiteral.appendAsJava(RexLiteral.java:726)
at org.apache.calcite.rex.RexLiteral.toJavaString(RexLiteral.java:427)
at org.apache.calcite.rex.RexLiteral.computeDigest(RexLiteral.java:289)
at org.apache.calcite.rex.RexLiteral.(RexLiteral.java:233)
at org.apache.calcite.rex.RexLiteral.toLiteral(RexLiteral.java:762)
at
org.apache.calcite.rex.RexLiteral.lambda$printSarg$4(RexLiteral.java:733)
at
org.apache.calcite.util.RangeSets$Printer.singleton(RangeSets.java:409)
at org.apache.calcite.util.RangeSets.forEach(RangeSets.java:249)
at org.apache.calcite.util.Sarg.lambda$printTo$0(Sarg.java:119)
at org.apache.calcite.linq4j.Ord.forEach(Ord.java:157)
at org.apache.calcite.util.Sarg.printTo(Sarg.java:115)
at org.apache.calcite.rex.RexLiteral.printSarg(RexLiteral.java:732)
at
org.apache.calcite.rex.RexLiteral.lambda$appendAsJava$1(RexLiteral.java:673)
at org.apache.calcite.util.Util.asStringBuilder(Util.java:2525)
at org.apache.calcite.rex.RexLiteral.appendAsJava(RexLiteral.java:672)
at org.apache.calcite.rex.RexLiteral.toJavaString(RexLiteral.java:427)
at org.apache.calcite.rex.RexLiteral.computeDigest(RexLiteral.java:289)
at org.apache.calcite.rex.RexLiteral.(RexLiteral.java:233)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:990)
at
org.apache.calcite.rex.RexBuilder.makeSearchArgumentLiteral(RexBuilder.java:1085)
at org.apache.calcite.rex.RexBuilder.makeIn(RexBuilder.java:1335)
at
org.apache.calcite.rex.RexBuilderTest.testMakeIn(RexBuilderTest.java:621)
{noformat}
The root cause is that {{RexLiteral#strictTypeName}} has different type name
strategies with what {{RexBuilder.makeLiteral}} follows, the best way to fix is
to make the rules synced, but here i only give a simple fix because the code
path only used for Sarg digest.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4473) Deprecate the config option TARGET_SCHEMA_FILE_PROP for HoodieFlinkStreamer
[
https://issues.apache.org/jira/browse/CALCITE-4473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen closed CALCITE-4473.
---
Resolution: Invalid
Close because i created in a wrong community, sorry for that.
> Deprecate the config option TARGET_SCHEMA_FILE_PROP for HoodieFlinkStreamer
> ---
>
> Key: CALCITE-4473
> URL: https://issues.apache.org/jira/browse/CALCITE-4473
> Project: Calcite
> Issue Type: Improvement
>Reporter: Danny Chen
>Priority: Major
>
> The option {{hoodie.deltastreamer.schemaprovider.source.schema.file}} is
> confusing and copied from the {{HoodieDeltaStreamer}}, we better give it a
> more readable name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4473) Deprecate the config option TARGET_SCHEMA_FILE_PROP for HoodieFlinkStreamer
Danny Chen created CALCITE-4473:
---
Summary: Deprecate the config option TARGET_SCHEMA_FILE_PROP for
HoodieFlinkStreamer
Key: CALCITE-4473
URL: https://issues.apache.org/jira/browse/CALCITE-4473
Project: Calcite
Issue Type: Improvement
Reporter: Danny Chen
The option {{hoodie.deltastreamer.schemaprovider.source.schema.file}} is
confusing and copied from the {{HoodieDeltaStreamer}}, we better give it a more
readable name.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4456) Allows all the value expressions for explicit row value constructor
[
https://issues.apache.org/jira/browse/CALCITE-4456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4456.
-
Resolution: Fixed
Fixed in
[4d413bb|https://github.com/apache/calcite/commit/4d413bb21fb0a18882c5066f1d75a02d5b021bac]
!
> Allows all the value expressions for explicit row value constructor
> ---
>
> Key: CALCITE-4456
> URL: https://issues.apache.org/jira/browse/CALCITE-4456
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> In SQL standard 2011 part 7 value expression, it defines the SQL syntax for
> explicit ROW value constructor to allows all the valid value expreesion:
> {code:sql}
> ::=
>
> |
> |
> ::=
>
> |
> |
> |
> |
> |
> |
> ::=
>
>
> | ROW
> |
> ::=
>
> {code}
> I also tried the PostgreSQL 9.6 for the query:
> {code:sql}
> create table t1(
> f0 int,
> f1 varchar(20)
> );
> insert into t1 values(1, 'abc');
> -- select row(t1.f0 + 1, t1.f1) from t1; -- outputs (2, abc)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4456) Allows all the value expressions for explicit row value constructor
[
https://issues.apache.org/jira/browse/CALCITE-4456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259360#comment-17259360
]
Danny Chen commented on CALCITE-4456:
-
Query like
{code:sql}
select row(t1.f0 + 1, t1.f1) from t1
{code}
is not supported.
> Allows all the value expressions for explicit row value constructor
> ---
>
> Key: CALCITE-4456
> URL: https://issues.apache.org/jira/browse/CALCITE-4456
> Project: Calcite
> Issue Type: Task
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In SQL standard 2011 part 7 value expression, it defines the SQL syntax for
> explicit ROW value constructor to allows all the valid value expreesion:
> {code:sql}
> ::=
>
> |
> |
> ::=
>
> |
> |
> |
> |
> |
> |
> ::=
>
>
> | ROW
> |
> ::=
>
> {code}
> I also tried the PostgreSQL 9.6 for the query:
> {code:sql}
> create table t1(
> f0 int,
> f1 varchar(20)
> );
> insert into t1 values(1, 'abc');
> -- select row(t1.f0 + 1, t1.f1) from t1; -- outputs (2, abc)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4456) Allows all the value expressions for explicit row value constructor
Danny Chen created CALCITE-4456:
---
Summary: Allows all the value expressions for explicit row value
constructor
Key: CALCITE-4456
URL: https://issues.apache.org/jira/browse/CALCITE-4456
Project: Calcite
Issue Type: Task
Components: core
Affects Versions: 1.26.0
Reporter: Danny Chen
Assignee: Danny Chen
Fix For: 1.27.0
In SQL standard 2011 part 7 value expression, it defines the SQL syntax for
explicit ROW value constructor to allows all the valid value expreesion:
{code:sql}
::=
|
|
::=
|
|
|
|
|
|
::=
| ROW
|
::=
{code}
I also tried the PostgreSQL 9.6 for the query:
{code:sql}
create table t1(
f0 int,
f1 varchar(20)
);
insert into t1 values(1, 'abc');
-- select row(t1.f0 + 1, t1.f1) from t1; -- outputs (2, abc)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4437) The Sort rel should be decorrelated even though it has fetch or limit when it is not inside a Correlate
[
https://issues.apache.org/jira/browse/CALCITE-4437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17250746#comment-17250746
]
Danny Chen commented on CALCITE-4437:
-
Would take a look if i found some time ~
> The Sort rel should be decorrelated even though it has fetch or limit when it
> is not inside a Correlate
> ---
>
> Key: CALCITE-4437
> URL: https://issues.apache.org/jira/browse/CALCITE-4437
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Ruben Q L
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The fix applied for CALCITE-4206 was "too drastic" and it resulted in Sort
> with fetch/offset being impossible to decorrelate in all cases.
> CALCITE-4333 addressed this issue but only partially (when the Sort with
> fetch/offset is on top on the plan). However, this solution is insufficient,
> because any Sort with fetch/offset that is not inside a Correlate can be
> decorrelated.
> Check this test in SqlToRelConverterTest (same test as CALCITE-4333, just
> with an extra LogicalProject on top of the LogicalSort):
> {code}
> @Test void testProjectSortLimitWithCorrelateInput() {
> final String sql = ""
> + "SELECT ename||deptno FROM\n"
> + "(SELECT deptno, ename\n"
> + "FROM\n"
> + "(SELECT DISTINCT deptno FROM emp) t1,\n"
> + " LATERAL (\n"
> + "SELECT ename, sal\n"
> + "FROM emp\n"
> + "WHERE deptno = t1.deptno)\n"
> + "ORDER BY ename DESC\n"
> + "LIMIT 3)";
> sql(sql).ok();
> }
> {code}
> The current plan is:
> {noformat}
> LogicalProject(EXPR$0=[||($1, CAST($0):VARCHAR NOT NULL)])
> LogicalSort(sort0=[$1], dir0=[DESC], fetch=[3])
> LogicalProject(DEPTNO=[$0], ENAME=[$1])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{0}])
> LogicalAggregate(group=[{0}])
> LogicalProject(DEPTNO=[$7])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(ENAME=[$1], SAL=[$5])
> LogicalFilter(condition=[=($7, $cor0.DEPTNO)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {noformat}
> It can actually decorrelated as:
> {noformat}
> LogicalProject(EXPR$0=[||($1, CAST($0):VARCHAR NOT NULL)])
> LogicalSort(sort0=[$1], dir0=[DESC], fetch=[3])
> LogicalProject(DEPTNO=[$0], ENAME=[$1])
> LogicalJoin(condition=[=($0, $3)], joinType=[inner])
> LogicalAggregate(group=[{0}])
> LogicalProject(DEPTNO=[$7])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalProject(ENAME=[$1], SAL=[$5], DEPTNO=[$7])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4413) Duplicate RAND() after pushdown when optimizing
[
https://issues.apache.org/jira/browse/CALCITE-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17237074#comment-17237074
]
Danny Chen commented on CALCITE-4413:
-
Use {{SqlOperator.isDeterministic}} to decide if to replace the calls when do
transformation.
> Duplicate RAND() after pushdown when optimizing
> ---
>
> Key: CALCITE-4413
> URL: https://issues.apache.org/jira/browse/CALCITE-4413
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Jiatao Tao
>Assignee: Jiatao Tao
>Priority: Major
>
> In CsvTest:
> SQL:
> {code:java}
> select *
> from
> (
> select empno, rand(1) as ran
> from EMPS
> where gender <> 'M'
> ) t
> where ran > 0.6
> {code}
>
> PLAN:
> {code:java}
> EnumerableProject(EMPNO=[$0], RAN=[RAND(1)])
> EnumerableInterpreter
> BindableTableScan(table=[[SALES, EMPS]], filters=[[AND(<>($3, 'M'),
> >(RAND(1), 0.6:DECIMAL(2, 1)))]])
> {code}
> We can see there are two "RAND(1)" and it changes the semantics.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4412) SqlParser MySQL mode fails to parse "INT(11)" type
[
https://issues.apache.org/jira/browse/CALCITE-4412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17235963#comment-17235963
]
Danny Chen commented on CALCITE-4412:
-
Yeah, Calcite INT type does not support precision yet. Isn't the integer type's
max precision just 10 ? Just curious ~
> SqlParser MySQL mode fails to parse "INT(11)" type
> --
>
> Key: CALCITE-4412
> URL: https://issues.apache.org/jira/browse/CALCITE-4412
> Project: Calcite
> Issue Type: Bug
> Components: server
>Affects Versions: 1.26.0
> Environment: Java 11
> Windows 10
>Reporter: Alex Ramos
>Priority: Major
>
> I am trying to use Calcite to parse some MySQL-style DDL. The parse fails on
> MySQL-style type declarations that include a display size e.g. int(11).
> Here is my test code:
> {code:java}
> public class SqlParserMysqlTest {
> private static final Config CONFIG = SqlParser.Config.DEFAULT
> .withLex(Lex.MYSQL).withConformance(SqlConformanceEnum.MYSQL_5)
> .withParserFactory(SqlDdlParserImpl.FACTORY);
> @Test
> public void testMysqlCreate() throws SqlParseException {
> SqlParser sqlParser = SqlParser.create(
> new SourceStringReader("create table `t1` (x int(11))"),
> CONFIG);
> SqlNode sqlNode = sqlParser.parseQuery();
> Assert.assertEquals(SqlKind.CREATE_TABLE, sqlNode.getKind());
> SqlCreateTable create = (SqlCreateTable) sqlNode;
> Assert.assertEquals("T1", create.name.getSimple());
> final SqlColumnDeclaration sqlColumnDeclaration =
> (SqlColumnDeclaration) create.columnList
> .get(0);
> Assert.assertEquals("X", sqlColumnDeclaration.name.getSimple());
> Assert.assertEquals("INTEGER",
> sqlColumnDeclaration.dataType.getTypeName().getSimple());
> }
> }
> {code}
> And here is the error:
> {noformat}
> org.apache.calcite.sql.parser.SqlParseException: Encountered "(" at line 1,
> column 25.
> Was expecting one of:
> "ARRAY" ...
> "AS" ...
> "DEFAULT" ...
> "GENERATED" ...
> "MULTISET" ...
> "NOT" ...
> "NULL" ...
> ")" ...
> "," ...
>
> at
> org.apache.calcite.sql.parser.ddl.SqlDdlParserImpl.convertException(SqlDdlParserImpl.java:394)
> at
> org.apache.calcite.sql.parser.ddl.SqlDdlParserImpl.normalizeException(SqlDdlParserImpl.java:157)
> at
> org.apache.calcite.sql.parser.SqlParser.handleException(SqlParser.java:140)
> at
> org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:155){noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4407) Support unparse special syntax when operator is DELETE
[
https://issues.apache.org/jira/browse/CALCITE-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17235247#comment-17235247
]
Danny Chen commented on CALCITE-4407:
-
Current interface {{SqlCall#getOperator}} only requires returning
{{SqlOperator}} instance, but the {{SqlShuttle}} always invokes
{{SqlOperator#createCall}}, which requires that the operator of {{SqlNode}}
must implement the {{createCall}} correctly.
The contract is very obscure, people can only find the problem when they use
the {{SqlShuttle}}.
I would suggest to strength the {{SqlCall}} of all the {{SqlNode}} instances to
return a specific {{SqlOperator}}, it always needs to implement the
{{#createCall}} correctly.
> Support unparse special syntax when operator is DELETE
> --
>
> Key: CALCITE-4407
> URL: https://issues.apache.org/jira/browse/CALCITE-4407
> Project: Calcite
> Issue Type: Wish
>Reporter: xzh_dz
>Priority: Major
> Labels: pull-request-available
> Attachments: image-2020-11-18-16-12-18-340.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This exception can be reproduced as below:
> SqlParserTest:
> {code:java}
> // code placeholder
> @Test void testSqlDeleteSqlBasicCallToString() throws Exception {
> final String sql0 = "delete from emps";
> final SqlNode sqlNode0 = getSqlParser(sql0).parseStmt();
> final SqlNode sqlNodeVisited0 = sqlNode0.accept(new SqlShuttle() {
> @Override public SqlNode visit(SqlIdentifier identifier) {
> return new SqlIdentifier(identifier.names,
> identifier.getParserPosition());
> }
> });
> System.out.println(sqlNodeVisited0.toString());
> }{code}
> Exception:
> {code:java}
> // code placeholder
> java.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlSyntax$7:
> SPECIALjava.lang.UnsupportedOperationException: class
> org.apache.calcite.sql.SqlSyntax$7: SPECIAL
> at org.apache.calcite.util.Util.needToImplement(Util.java:1080) at
> org.apache.calcite.sql.SqlSyntax$7.unparse(SqlSyntax.java:128) at
> org.apache.calcite.sql.SqlOperator.unparse(SqlOperator.java:377) at
> org.apache.calcite.sql.SqlDialect.unparseCall(SqlDialect.java:453) at
> org.apache.calcite.sql.SqlCall.unparse(SqlCall.java:103) at
> org.apache.calcite.sql.SqlNode.toSqlString(SqlNode.java:155)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4406) SqlTableRef OPERATOR should create a SqlTableRef as the call
[
https://issues.apache.org/jira/browse/CALCITE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4406.
-
Resolution: Fixed
Fixed in
[61771cc|https://github.com/apache/calcite/commit/61771ccdb9148f6d2e0bb3e36a4e54d614321eb8]
~
> SqlTableRef OPERATOR should create a SqlTableRef as the call
>
>
> Key: CALCITE-4406
> URL: https://issues.apache.org/jira/browse/CALCITE-4406
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2020-11-18-16-01-55-504.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {{SqlTableRef}} OPERATOR should create a SqlTableRef as the call, so that
> after substitution of {{SqlShuttle}}, it is still a {{SqlTableRef}} instead
> of {{SqlBasicCall}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4406) SqlTableRef OPERATOR should create a SqlTableRef as the call
[
https://issues.apache.org/jira/browse/CALCITE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17234381#comment-17234381
]
Danny Chen commented on CALCITE-4406:
-
You are right, thanks for the review ~
> SqlTableRef OPERATOR should create a SqlTableRef as the call
>
>
> Key: CALCITE-4406
> URL: https://issues.apache.org/jira/browse/CALCITE-4406
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Attachments: image-2020-11-18-16-01-55-504.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{SqlTableRef}} OPERATOR should create a SqlTableRef as the call, so that
> after substitution of {{SqlShuttle}}, it is still a {{SqlTableRef}} instead
> of {{SqlBasicCall}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4406) SqlTableRef OPERATOR should create a SqlTableRef as the call
Danny Chen created CALCITE-4406:
---
Summary: SqlTableRef OPERATOR should create a SqlTableRef as the
call
Key: CALCITE-4406
URL: https://issues.apache.org/jira/browse/CALCITE-4406
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.26.0
Reporter: Danny Chen
Assignee: Danny Chen
Fix For: 1.27.0
{{SqlTableRef}} OPERATOR should create a SqlTableRef as the call, so that after
substitution of {{SqlShuttle}}, it is still a {{SqlTableRef}} instead of
{{SqlBasicCall}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4364) Simplify "a IN (1, 2) AND a = 1" to "a = 1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17231120#comment-17231120
]
Danny Chen commented on CALCITE-4364:
-
Yes, i'm fixing it.
> Simplify "a IN (1, 2) AND a = 1" to "a = 1"
> ---
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
> Calcite should simplify "\{{a IN (1, 2) AND a = 1}}" to "\{{a = 1}}". Check
> this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4364) Simplify "a IN (1, 2) AND a = 1" to "a = 1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4364.
-
Resolution: Fixed
Fixed in
[5e9943a|https://github.com/apache/calcite/commit/5e9943aa1f51a97068fc37d53dea1d447570becc]
~
> Simplify "a IN (1, 2) AND a = 1" to "a = 1"
> ---
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
> Calcite should simplify "\{{a IN (1, 2) AND a = 1}}" to "\{{a = 1}}". Check
> this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4396) Allows table valued functions of FROM and JOIN context without TABLE clause
[
https://issues.apache.org/jira/browse/CALCITE-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen updated CALCITE-4396:
Description:
In current code base, user can use a table valued function mainly for 2 kinds
of SQL statements:
{code:sql}
-- select from the table valued function directly
SELECT ... FROM TABLE(my_tvf(...));
-- join the table valued function with LATERAL keyword
... t1 JOIN LATERAL TABLE(my_tvf(...)) ON ...
{code}
While since version 12.1+, Oracle supports syntax without TABLE keyword, thus
you can write SQL as following[1]:
{code:sql}
-- select from the table valued function directly
SELECT ... FROM my_tvf(...);
-- join the table valued function with LATERAL keyword
... t1 JOIN my_tvf(...) ON ...
{code}
SQL-SERVER also allows select from the table valued function directly without
the explicit TABLE keyword, but they need the CROSS APPLY clause for table and
function join. [2]
We already had a discussion on the DEV mailing list, see [3].
I propose to support the Oracle style table valued function syntax: to omit the
TABLE keyword because the syntax is straight-forward and concise.
Of course, this syntax is only valid under Oracle SQL conformance.
[1]
https://livesql.oracle.com/apex/livesql/file/tutorial_GSOTSK8FWLYZOG5CJJ9KPX7RX.html
[2]
https://docs.microsoft.com/en-us/sql/relational-databases/user-defined-functions/create-user-defined-functions-database-engine?view=sql-server-ver15#TVF
[3]
https://lists.apache.org/x/thread.html/ra98db08e280ddd9adeef62f456f61aedfdf7756e215cb4d66e2a52c9@%3Cdev.calcite.apache.org%3E
was:
In current code base, user can use a table valued function mainly for 2 kinds
of SQL statements:
{code:sql}
-- select from the table valued function directly
SELECT ... FROM TABLE(my_tvf(...));
-- join the table valued function with LATERAL keyword
... t1 JOIN LATERAL TABLE(my_tvf(...)) ON ...
{code}
While since version 12.1+, Oracle supports syntax without TABLE keyword, thus
you can write SQL as following:
{code:sql}
-- select from the table valued function directly
SELECT ... FROM my_tvf(...);
-- join the table valued function with LATERAL keyword
... t1 JOIN my_tvf(...) ON ...
{code}
SQL-SERVER also allows select from the table valued function directly without
the explicit TABLE keyword, but they need the CROSS APPLY clause for table and
function join. [2]
We already had a discussion on the DEV mailing list, see [3].
I propose to support the Oracle style table valued function syntax: to omit the
TABLE keyword because the syntax is straight-forward and concise.
Of course, this syntax is only valid under Oracle SQL conformance.
[1]
https://livesql.oracle.com/apex/livesql/file/tutorial_GSOTSK8FWLYZOG5CJJ9KPX7RX.html
[2]
https://docs.microsoft.com/en-us/sql/relational-databases/user-defined-functions/create-user-defined-functions-database-engine?view=sql-server-ver15#TVF
[3]
https://lists.apache.org/x/thread.html/ra98db08e280ddd9adeef62f456f61aedfdf7756e215cb4d66e2a52c9@%3Cdev.calcite.apache.org%3E
> Allows table valued functions of FROM and JOIN context without TABLE clause
> ---
>
> Key: CALCITE-4396
> URL: https://issues.apache.org/jira/browse/CALCITE-4396
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Fix For: 1.27.0
>
>
> In current code base, user can use a table valued function mainly for 2 kinds
> of SQL statements:
> {code:sql}
> -- select from the table valued function directly
> SELECT ... FROM TABLE(my_tvf(...));
> -- join the table valued function with LATERAL keyword
> ... t1 JOIN LATERAL TABLE(my_tvf(...)) ON ...
> {code}
> While since version 12.1+, Oracle supports syntax without TABLE keyword, thus
> you can write SQL as following[1]:
> {code:sql}
> -- select from the table valued function directly
> SELECT ... FROM my_tvf(...);
> -- join the table valued function with LATERAL keyword
> ... t1 JOIN my_tvf(...) ON ...
> {code}
> SQL-SERVER also allows select from the table valued function directly without
> the explicit TABLE keyword, but they need the CROSS APPLY clause for table
> and function join. [2]
> We already had a discussion on the DEV mailing list, see [3].
> I propose to support the Oracle style table valued function syntax: to omit
> the TABLE keyword because the syntax is straight-forward and concise.
> Of course, this syntax is only valid under Oracle SQL conformance.
> [1]
> https://livesql.oracle.com/apex/livesql/file/tutorial_GSOTSK8FWLYZOG5CJJ9KPX7RX.html
> [2]
> https://docs.microsoft.com/en-us/sql/relational-databases/user-defined-functions/create-user-defined-functions-database-engine?view=sql-server-ver15#TVF
> [3]
>
[jira] [Created] (CALCITE-4396) Allows table valued functions of FROM and JOIN context without TABLE clause
Danny Chen created CALCITE-4396:
---
Summary: Allows table valued functions of FROM and JOIN context
without TABLE clause
Key: CALCITE-4396
URL: https://issues.apache.org/jira/browse/CALCITE-4396
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.26.0
Reporter: Danny Chen
Assignee: Danny Chen
Fix For: 1.27.0
In current code base, user can use a table valued function mainly for 2 kinds
of SQL statements:
{code:sql}
-- select from the table valued function directly
SELECT ... FROM TABLE(my_tvf(...));
-- join the table valued function with LATERAL keyword
... t1 JOIN LATERAL TABLE(my_tvf(...)) ON ...
{code}
While since version 12.1+, Oracle supports syntax without TABLE keyword, thus
you can write SQL as following:
{code:sql}
-- select from the table valued function directly
SELECT ... FROM my_tvf(...);
-- join the table valued function with LATERAL keyword
... t1 JOIN my_tvf(...) ON ...
{code}
SQL-SERVER also allows select from the table valued function directly without
the explicit TABLE keyword, but they need the CROSS APPLY clause for table and
function join. [2]
We already had a discussion on the DEV mailing list, see [3].
I propose to support the Oracle style table valued function syntax: to omit the
TABLE keyword because the syntax is straight-forward and concise.
Of course, this syntax is only valid under Oracle SQL conformance.
[1]
https://livesql.oracle.com/apex/livesql/file/tutorial_GSOTSK8FWLYZOG5CJJ9KPX7RX.html
[2]
https://docs.microsoft.com/en-us/sql/relational-databases/user-defined-functions/create-user-defined-functions-database-engine?view=sql-server-ver15#TVF
[3]
https://lists.apache.org/x/thread.html/ra98db08e280ddd9adeef62f456f61aedfdf7756e215cb4d66e2a52c9@%3Cdev.calcite.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4364) Simplify "a IN (1, 2) AND a = 1" to "a = 1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17230376#comment-17230376
]
Danny Chen commented on CALCITE-4364:
-
I'm going to merge within 24 hours if there are no more review comments ~
> Simplify "a IN (1, 2) AND a = 1" to "a = 1"
> ---
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> Calcite should simplify "\{{a IN (1, 2) AND a = 1}}" to "\{{a = 1}}". Check
> this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-4364) Simplify "a IN (1, 2) AND a = 1" to "a = 1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen reassigned CALCITE-4364:
---
Assignee: Danny Chen
> Simplify "a IN (1, 2) AND a = 1" to "a = 1"
> ---
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> Calcite should simplify "\{{a IN (1, 2) AND a = 1}}" to "\{{a = 1}}". Check
> this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4364) Simplify "a IN (1, 2) AND a = 1" to "a = 1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17229760#comment-17229760
]
Danny Chen commented on CALCITE-4364:
-
Thanks, the latest change:
1. Refactor out {{flattenOperands}} and reuse the existing code.
2. Move {{canNotMerge}} to {{canMerge}} and add a test case for it
> Simplify "a IN (1, 2) AND a = 1" to "a = 1"
> ---
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> Calcite should simplify "\{{a IN (1, 2) AND a = 1}}" to "\{{a = 1}}". Check
> this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4364) "a in (1, 2) and a = 1" should be simplified to "a=1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228965#comment-17228965
]
Danny Chen commented on CALCITE-4364:
-
Thanks for the review [~julianhyde], i have updated the PR based on your
comments, the main changes:
1. Add test for {{RangeSets.isOpenInterval}}
2. When expanding SEARCH, promote "AND(AND(>($0, 0), <($0, 10)), IS NOT
NULL($1))" to "AND(>($0, 0), <($0, 10), IS NOT NULL($1))"
3. Move {{Sarg.isSimple}} out
> "a in (1, 2) and a = 1" should be simplified to "a=1"
> -
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> Check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4364) "a in (1, 2) and a = 1" should be simplified to "a=1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228965#comment-17228965
]
Danny Chen edited comment on CALCITE-4364 at 11/10/20, 4:28 AM:
Thanks for the review [~julianhyde], i have updated the PR based on your
comments, the main changes:
1. Add test for {{RangeSets.isOpenInterval}}
2. When expanding SEARCH, promote
"AND(AND(>($0, 0), <($0, 10)), IS NOT NULL($1))"
to "AND(>($0, 0), <($0, 10), IS NOT NULL($1))"
3. Move {{Sarg.isSimple}} out
was (Author: danny0405):
Thanks for the review [~julianhyde], i have updated the PR based on your
comments, the main changes:
1. Add test for {{RangeSets.isOpenInterval}}
2. When expanding SEARCH, promote "AND(AND(>($0, 0), <($0, 10)), IS NOT
NULL($1))" to "AND(>($0, 0), <($0, 10), IS NOT NULL($1))"
3. Move {{Sarg.isSimple}} out
> "a in (1, 2) and a = 1" should be simplified to "a=1"
> -
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 6h 50m
> Remaining Estimate: 0h
>
> Check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4364) "a in (1, 2) and a = 1" should be simplified to "a=1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228336#comment-17228336
]
Danny Chen commented on CALCITE-4364:
-
Hi, Julian, can you take a look again if you have time ? Thanks in advance so
much ~
> "a in (1, 2) and a = 1" should be simplified to "a=1"
> -
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 6h
> Remaining Estimate: 0h
>
> Check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4364) "a in (1, 2) and a = 1" should be simplified to "a=1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17227109#comment-17227109
]
Danny Chen edited comment on CALCITE-4364 at 11/6/20, 3:40 AM:
---
Thanks Julian ~
> Does the PR have lots of plan changes
No, at least from the tests of Calcite, there are no many plan diffs.
> But we have to expand the small sargs into comparisons in order to avoid plan
> changes
I agree, i can fix it together in this PR, but this would bring in many plan
diffs because we already have many small Sargs in our plans.
I have updated the PR according your comments, please take a look if you have
time, thanks so much ~
was (Author: danny0405):
Thanks Julian ~
> Does the PR have lots of plan changes
No, at least from the tests of Calcite, there are no many plan diffs.
> But we have to expand the small sargs into comparisons in order to avoid plan
> changes
I agree, i can fix it together in this PR, but this would bring in many plan
diffs because we already have many small Sargs in our plans.
> "a in (1, 2) and a = 1" should be simplified to "a=1"
> -
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> Check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4364) "a in (1, 2) and a = 1" should be simplified to "a=1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17227109#comment-17227109
]
Danny Chen commented on CALCITE-4364:
-
Thanks Julian ~
> Does the PR have lots of plan changes
No, at least from the tests of Calcite, there are no many plan diffs.
> But we have to expand the small sargs into comparisons in order to avoid plan
> changes
I agree, i can fix it together in this PR, but this would bring in many plan
diffs because we already have many small Sargs in our plans.
> "a in (1, 2) and a = 1" should be simplified to "a=1"
> -
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> Check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3457) RexSimplify incorrectly simplifies IS NOT NULL operator with ITEM call
[
https://issues.apache.org/jira/browse/CALCITE-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17226568#comment-17226568
]
Danny Chen commented on CALCITE-3457:
-
The check of this patch is still valid, please review the fix code
https://github.com/apache/calcite/pull/2246/files
> RexSimplify incorrectly simplifies IS NOT NULL operator with ITEM call
> --
>
> Key: CALCITE-3457
> URL: https://issues.apache.org/jira/browse/CALCITE-3457
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.22.0
>Reporter: Vova Vysotskyi
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> In CALCITE-3390 ITEM was marked with {{Policy.ANY}} strong policy, but
> according to its JavaDoc, the result may be null if and only if at least one
> of its arguments is null. This statement was used in
> {{RexSimplify.simplifyIsNotNull()}} method, so {{t1.c_nationkey[0] is not
> null}} will be simplified to {{IS NOT NULL($0)}} which is wrong, since array
> may be empty, or index may be less than the size of the array.
> Unit test which helps to reproduce this issue:
> {noformat}
> @Test public void testSimplifyItemIsNotNull() {
> String query = "select * from sales.customer as t1 where
> t1.c_nationkey[0] is not null";
> sql(query)
> .withTester(t -> createDynamicTester())
> .withRule(ReduceExpressionsRule.FILTER_INSTANCE)
> .check();
> }
> {noformat}
> Returns plan with incorrectly simplified ITEM expression:
> {noformat}
> LogicalProject(**=[$1])
> LogicalFilter(condition=[IS NOT NULL($0)])
> LogicalTableScan(table=[[CATALOG, SALES, CUSTOMER]])
> {noformat}
> But the initial intention of CALCITE-3390 was to allow pushing ITEM
> expression to the right input of left-outer-join.
> I propose to add a new element to the {{Policy}} which will have a relaxed
> condition - expression is null if at least one of its arguments is null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4377) Fix the return nullability inference during rex simplification
Danny Chen created CALCITE-4377:
---
Summary: Fix the return nullability inference during rex
simplification
Key: CALCITE-4377
URL: https://issues.apache.org/jira/browse/CALCITE-4377
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.26.0
Reporter: Danny Chen
Assignee: Danny Chen
Fix For: 1.27.0
Check test of {{RexProgramTest.reproducerFor3457}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4233) Elasticsearch Dismax API is not supported in calcite
[
https://issues.apache.org/jira/browse/CALCITE-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17225056#comment-17225056
]
Danny Chen commented on CALCITE-4233:
-
Thanks for the fix, Julian ~ I should have taken care of the commit message ~
> Elasticsearch Dismax API is not supported in calcite
>
>
> Key: CALCITE-4233
> URL: https://issues.apache.org/jira/browse/CALCITE-4233
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Shlok Srivastava
>Priority: Major
> Labels: QueryBuilder, calcite, dismax, elasticsearch
> Fix For: 1.27.0
>
>
> Currently, Calcite use constant_score API to build all the queries. which do
> not boost the documents based on relevance score from any matching clause
> which is supported by disMax API. It does not support dismax query builders -
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-dis-max-query.html.]
>
> Dismax query -
> {code:java}
> GET /_search
> {
> "query": {
> "dis_max": {
> "queries": [
> {
> "bool": {
> "should": [
> {
> "term": {
> "Name": "James"
> }
> },
> {
> "term": {
> "Name": "Peter"
> }
> },
> {
> "term": {
> "Name": "Harry"
> }
> },
>
> }
> ]
> }
> ]
> }
> }{code}
> Suggested solution - Queries with OR conditions should use disMax builders
> to fetch the best matching documents.
>
> Sample SQL query -
> {code:java}
> WHERE Name="James" OR Name="Peter" OR Name="Harry" {code}
> Sample RelNode -
> {code:java}
> relB.or(relB.equals(relb.literal("Name"),relb.literal"James"),
> relB.equals(relb.literal("Name"),relb.literal"Peter"),
> relB.equals(relb.literal("Name"),relb.literal"Harry"){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4364) "a in (1, 2) and a = 1" should be simplified to "a=1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224509#comment-17224509
]
Danny Chen commented on CALCITE-4364:
-
Julian, can you take a look again, i expanded the sarg fix logic as:
# A Sarg has complexity greater than 1;
# The terms are reduced as simpler Sarg points.
Compared to before, more sargs can be merged.
> "a in (1, 2) and a = 1" should be simplified to "a=1"
> -
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Liya Fan
>Priority: Major
> Fix For: 1.27.0
>
>
> Check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4233) Elasticsearch Dismax API is not supported in calcite
[
https://issues.apache.org/jira/browse/CALCITE-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4233.
-
Fix Version/s: 1.27.0
Resolution: Fixed
Fixed in
[b20e0bf|https://github.com/apache/calcite/commit/b20e0bf6ca9b605fa4a6203bd06454abd6a98ce2],
thanks for the PR, [~shlok7296] ~
> Elasticsearch Dismax API is not supported in calcite
>
>
> Key: CALCITE-4233
> URL: https://issues.apache.org/jira/browse/CALCITE-4233
> Project: Calcite
> Issue Type: Improvement
> Components: elasticsearch-adapter
>Reporter: Shlok Srivastava
>Priority: Major
> Labels: QueryBuilder, calcite, dismax, elasticsearch
> Fix For: 1.27.0
>
>
> Currently, Calcite use constant_score API to build all the queries. which do
> not boost the documents based on relevance score from any matching clause
> which is supported by disMax API. It does not support dismax query builders -
> [https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-dis-max-query.html.]
>
> Dismax query -
> {code:java}
> GET /_search
> {
> "query": {
> "dis_max": {
> "queries": [
> {
> "bool": {
> "should": [
> {
> "term": {
> "Name": "James"
> }
> },
> {
> "term": {
> "Name": "Peter"
> }
> },
> {
> "term": {
> "Name": "Harry"
> }
> },
>
> }
> ]
> }
> ]
> }
> }{code}
> Suggested solution - Queries with OR conditions should use disMax builders
> to fetch the best matching documents.
>
> Sample SQL query -
> {code:java}
> WHERE Name="James" OR Name="Peter" OR Name="Harry" {code}
> Sample RelNode -
> {code:java}
> relB.or(relB.equals(relb.literal("Name"),relb.literal"James"),
> relB.equals(relb.literal("Name"),relb.literal"Peter"),
> relB.equals(relb.literal("Name"),relb.literal"Harry"){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4106) TypeCoercionImpl#inOperationCoercion should consider listCoerced
[ https://issues.apache.org/jira/browse/CALCITE-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen resolved CALCITE-4106. - Fix Version/s: 1.27.0 Resolution: Fixed Fixed in [e7c579f|https://github.com/apache/calcite/commit/e7c579ff5bcc88c2ca0173192d9accd5786bca23], thanks for the PR [~Aron.tao] ~ > TypeCoercionImpl#inOperationCoercion should consider listCoerced > > > Key: CALCITE-4106 > URL: https://issues.apache.org/jira/browse/CALCITE-4106 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Jiatao Tao >Assignee: Jiatao Tao >Priority: Major > Labels: pull-request-available > Fix For: 1.27.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Current "inOperationCoercion" only returns "coerced", should consider > listCoerced too. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4364) "a in (1, 2) and a = 1" should be simplified to "a=1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17224455#comment-17224455
]
Danny Chen commented on CALCITE-4364:
-
[~fan_li_ya], i already fired a fix in
https://github.com/apache/calcite/pull/2238.
> "a in (1, 2) and a = 1" should be simplified to "a=1"
> -
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Assignee: Liya Fan
>Priority: Major
> Fix For: 1.27.0
>
>
> Check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-4365) SEARCHes in ANDs and ORs cannot be simplified if the complexity of its SARG can actually be reduced to 1
[
https://issues.apache.org/jira/browse/CALCITE-4365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen closed CALCITE-4365.
---
Fix Version/s: 1.27.0
Assignee: Danny Chen
Resolution: Duplicate
Close because it is duplicated.
> SEARCHes in ANDs and ORs cannot be simplified if the complexity of its SARG
> can actually be reduced to 1
>
>
> Key: CALCITE-4365
> URL: https://issues.apache.org/jira/browse/CALCITE-4365
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Caizhi Weng
>Assignee: Danny Chen
>Priority: Major
> Fix For: 1.27.0
>
>
> Consider the following test case in {{RexProgramTest}}.
> {code:java}
> @Test void testSimplifySearch() {
> // (deptno <> 20 OR deptno IS NULL) AND deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(10), literal(20)),
> eq(vInt(), literal(10)));
> checkSimplify2(e, "=(?0.int0, 10)", "=(?0.int0, 10)");
> }
> {code}
> We expect that {{AND(SEARCH(?0, [10, 20], =(?0, 10)))}} can be simplified to
> {{=(?0, 10)}} but fails. This is because {{RexSimplify#simplifyAnd}} and
> {{RexSimplify#simplifyOrs}} does not deal with the case when the complexity
> of {{SargCollector}} is 1.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4364) "a in (1, 2) and a = 1" should be simplified to "a=1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17223329#comment-17223329
]
Danny Chen commented on CALCITE-4364:
-
Tested, not fixed by CALCITE-4352 yet.
> "a in (1, 2) and a = 1" should be simplified to "a=1"
> -
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
> Fix For: 1.27.0
>
>
> Check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4364) "a in (1, 2) and a = 1" should be simplified to "a=1"
[
https://issues.apache.org/jira/browse/CALCITE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen updated CALCITE-4364:
Description:
Check this test in {{RexProgramTest}}:
{code:java}
@Test void testSimplifyInAnd() {
// deptno in (20, 10) and deptno = 10
// ==>
// deptno = 10
final RexNode e =
and(
in(vInt(), literal(20), literal(10)),
eq(vInt(), literal(10)));
checkSimplify(e, "=(?0.int0, 10)");
}
{code}
was:
Check this test in {{RexProgramTest}}:
```java
@Test void testSimplifyInAnd() {
// deptno in (20, 10) and deptno = 10
// ==>
// deptno = 10
final RexNode e =
and(
in(vInt(), literal(20), literal(10)),
eq(vInt(), literal(10)));
checkSimplify(e, "=(?0.int0, 10)");
}
```
> "a in (1, 2) and a = 1" should be simplified to "a=1"
> -
>
> Key: CALCITE-4364
> URL: https://issues.apache.org/jira/browse/CALCITE-4364
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.26.0
>Reporter: Danny Chen
>Priority: Major
> Fix For: 1.27.0
>
>
> Check this test in {{RexProgramTest}}:
> {code:java}
> @Test void testSimplifyInAnd() {
> // deptno in (20, 10) and deptno = 10
> // ==>
> // deptno = 10
> final RexNode e =
> and(
> in(vInt(), literal(20), literal(10)),
> eq(vInt(), literal(10)));
> checkSimplify(e, "=(?0.int0, 10)");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4364) "a in (1, 2) and a = 1" should be simplified to "a=1"
Danny Chen created CALCITE-4364:
---
Summary: "a in (1, 2) and a = 1" should be simplified to "a=1"
Key: CALCITE-4364
URL: https://issues.apache.org/jira/browse/CALCITE-4364
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.26.0
Reporter: Danny Chen
Fix For: 1.27.0
Check this test in {{RexProgramTest}}:
```java
@Test void testSimplifyInAnd() {
// deptno in (20, 10) and deptno = 10
// ==>
// deptno = 10
final RexNode e =
and(
in(vInt(), literal(20), literal(10)),
eq(vInt(), literal(10)));
checkSimplify(e, "=(?0.int0, 10)");
}
```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-4354) ITEM operator does not support synthetic struct type
[
https://issues.apache.org/jira/browse/CALCITE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221917#comment-17221917
]
Danny Chen edited comment on CALCITE-4354 at 10/28/20, 2:42 AM:
I tried this SQL in PostgreSQL 9.6
{code:sql}
create table t1(
f0 integer[],
f1 varchar(20)
);
insert into t1 values('{1, 2, 3}', 'abc');
select f0[1] from t1; -- outputs 1
{code}
I also found this access rules in SQL standard 2011 6.24
{code:java}
1) If the value of or is
the null value, then the result of is the null value.
2) Let i be the value of . Case:
a) If i is greater than zero and less than or equal to the cardinality of
, then the result of is the
value of the i-th element of the value of .
b) Otherwise, an exception condition is raised: data exception — array element
error.
{code}
So the array type is index 1-based. We can follow this for row type.
was (Author: danny0405):
I tried this SQL in PostgreSQL 9.6
{code:sql}
create table t1(
f0 integer[],
f1 varchar(20)
);
insert into t1 values('{1, 2, 3}', 'abc');
select f0[1] from t1; -- outputs 1
{code}
I also found this access rules in SQL standard 2011 6.24
{code:noformat}
1) If the value of or is
the null value, then the result of is the null value.
2) Let i be the value of . Case:
a) If i is greater than zero and less than or equal to the cardinality of
, then the result of is the
value of the i-th element of the value of .
b) Otherwise, an exception condition is raised: data exception — array element
error.
{code}
So the array type is index 1-based. We can follow this for row type.
> ITEM operator does not support synthetic struct type
>
>
> Key: CALCITE-4354
> URL: https://issues.apache.org/jira/browse/CALCITE-4354
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.27.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> The current implementation of the "ITEM" operator only supports struct/row
> type when this type if based on a class with named fields (that is, a
> non-synthetic type).
> For those non-synthetic struct types, the "ITEM" operator can be used to
> access named fields via a "string"-typed argument
> ([SqlItemOperator#96|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L96]).
> The type checker accepts to apply "ITEM" on "ANY" type
> ([SqlItemOperator#49|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L49]),
> and the operand checker only accepts "string"-based values
> ([SqlItemOperator.java#105|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L105]).
> [SqlValidatorTest.java#L11933|https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/test/SqlValidatorTest.java#L11933]
> is an example of application of the "ITEM" operator over a struct with named
> fields.
> However, the “getAllowedSignatures” method
> ([SqlItemOperator.java#116|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L116])
> does not reflect this, and asserts a signature as follows:
> "[]" or "[]".
> "ITEM" operator could be enriched with the support of synthetic struct/row
> type, with a positional access to the fields with a signature
> "[]".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4354) ITEM operator does not support synthetic struct type
[
https://issues.apache.org/jira/browse/CALCITE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221917#comment-17221917
]
Danny Chen commented on CALCITE-4354:
-
I tried this SQL in PostgreSQL 9.6
{code:sql}
create table t1(
f0 integer[],
f1 varchar(20)
);
insert into t1 values('{1, 2, 3}', 'abc');
select f0[1] from t1; -- outputs 1
{code}
I also found this access rules in SQL standard 2011 6.24
{code:noformat}
1) If the value of or is
the null value, then the result of is the null value.
2) Let i be the value of . Case:
a) If i is greater than zero and less than or equal to the cardinality of
, then the result of is the
value of the i-th element of the value of .
b) Otherwise, an exception condition is raised: data exception — array element
error.
{code}
So the array type is index 1-based. We can follow this for row type.
> ITEM operator does not support synthetic struct type
>
>
> Key: CALCITE-4354
> URL: https://issues.apache.org/jira/browse/CALCITE-4354
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.27.0
>Reporter: Alessandro Solimando
>Assignee: Alessandro Solimando
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> The current implementation of the "ITEM" operator only supports struct/row
> type when this type if based on a class with named fields (that is, a
> non-synthetic type).
> For those non-synthetic struct types, the "ITEM" operator can be used to
> access named fields via a "string"-typed argument
> ([SqlItemOperator#96|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L96]).
> The type checker accepts to apply "ITEM" on "ANY" type
> ([SqlItemOperator#49|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L49]),
> and the operand checker only accepts "string"-based values
> ([SqlItemOperator.java#105|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L105]).
> [SqlValidatorTest.java#L11933|https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/test/SqlValidatorTest.java#L11933]
> is an example of application of the "ITEM" operator over a struct with named
> fields.
> However, the “getAllowedSignatures” method
> ([SqlItemOperator.java#116|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L116])
> does not reflect this, and asserts a signature as follows:
> "[]" or "[]".
> "ITEM" operator could be enriched with the support of synthetic struct/row
> type, with a positional access to the fields with a signature
> "[]".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4354) ITEM operator does not support synthetic struct type
[ https://issues.apache.org/jira/browse/CALCITE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17221216#comment-17221216 ] Danny Chen commented on CALCITE-4354: - I'm fine with the change. What do you think [~zabetak] and [~julianhyde] ? > ITEM operator does not support synthetic struct type > > > Key: CALCITE-4354 > URL: https://issues.apache.org/jira/browse/CALCITE-4354 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.27.0 >Reporter: Alessandro Solimando >Assignee: Alessandro Solimando >Priority: Minor > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > The current implementation of the "ITEM" operator only supports struct/row > type when this type if based on a class with named fields (that is, a > non-synthetic type). > For those non-synthetic struct types, the "ITEM" operator can be used to > access named fields via a "string"-typed argument > ([SqlItemOperator#96|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L96]). > The type checker accepts to apply "ITEM" on "ANY" type > ([SqlItemOperator#49|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L49]), > and the operand checker only accepts "string"-based values > ([SqlItemOperator.java#105|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L105]). > [SqlValidatorTest.java#L11933|https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/test/SqlValidatorTest.java#L11933] > is an example of application of the "ITEM" operator over a struct with named > fields. > However, the “getAllowedSignatures” method > ([SqlItemOperator.java#116|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L116]) > does not reflect this, and asserts a signature as follows: > "[]" or "[]". > "ITEM" operator could be enriched with the support of synthetic struct/row > type, with a positional access to the fields with a signature > "[]". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4354) ITEM operator does not support synthetic struct type
[ https://issues.apache.org/jira/browse/CALCITE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220618#comment-17220618 ] Danny Chen commented on CALCITE-4354: - Does the SQL standard allows signature "[]" ? > ITEM operator does not support synthetic struct type > > > Key: CALCITE-4354 > URL: https://issues.apache.org/jira/browse/CALCITE-4354 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.27.0 >Reporter: Alessandro Solimando >Assignee: Alessandro Solimando >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The current implementation of the "ITEM" operator only supports struct/row > type when this type if based on a class with named fields (that is, a > non-synthetic type). > For those non-synthetic struct types, the "ITEM" operator can be used to > access named fields via a "string"-typed argument > ([SqlItemOperator#96|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L96]). > The type checker accepts to apply "ITEM" on "ANY" type > ([SqlItemOperator#49|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L49]), > and the operand checker only accepts "string"-based values > ([SqlItemOperator.java#105|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L105]). > [SqlValidatorTest.java#L11933|https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/test/SqlValidatorTest.java#L11933] > is an example of application of the "ITEM" operator over a struct with named > fields. > However, the “getAllowedSignatures” method > ([SqlItemOperator.java#116|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L116]) > does not reflect this, and asserts a signature as follows: > "[]" or "[]". > "ITEM" operator could be enriched with the support of synthetic struct/row > type, with a positional access to the fields with a signature > "[]". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4340) Correlated Queries in ON clause do not work when referring to left side
[
https://issues.apache.org/jira/browse/CALCITE-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17220554#comment-17220554
]
Danny Chen commented on CALCITE-4340:
-
Thanks, there are 2 PRs, which one is the fix.
> Correlated Queries in ON clause do not work when referring to left side
> ---
>
> Key: CALCITE-4340
> URL: https://issues.apache.org/jira/browse/CALCITE-4340
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: James Starr
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Changes from CALCITE-4210 does not robustly support correlated queries in ON
> clauses.
> For the short term I am going revert the logic for supporting ON clause and
> throw an exception when correlated queries occur in ON clause.
> Then I will follow up with a fix that will support single subqueries in on
> clauses. This will require fixing the offset in Blackboard.register,
> correctly detect if correlated variable is on the being used and adding a
> rule RelDecorrelator joined decorrelations.
> Given:
> {code:sql}
> SELECT *
> FROM dept
> LEFT JOIN bonus ON bonus.job = (
> SELECT emp.job
> FROM emp
> WHERE emp.deptno = dept.deptno
> )
> {code}
> Should generate
> {code}
> LogicalProject(DEPTNO=[$0], NAME=[$1], ENAME=[$2], JOB=[$3], SAL=[$4],
> COMM=[$5])
> LogicalCorrelate(correlation=[$cor0], joinType=[left],
> requiredColumns=[{0}]) //requiring dept.DEPTNO as the correlated value
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> LogicalFilter(condition=[=($1, $4)]) //This is comparing bonus.job =
> emp.job
> LogicalJoin(condition=[true], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> LogicalAggregate(group=[{}], agg#0=[SINGLE_VALUE($0)])
> LogicalProject(JOB=[$2])
> LogicalFilter(condition=[=($7, $cor0.DEPTNO)]) //all employees
> for a given department
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> But instead generates:
> {code}
> LogicalProject(DEPTNO=[$0], NAME=[$1], ENAME=[$2], JOB=[$3], SAL=[$4],
> COMM=[$5])
> LogicalJoin(condition=[=($3, $0)], joinType=[left])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT]])
> LogicalCorrelate(correlation=[$cor0], joinType=[left],
> requiredColumns=[{0}])
> LogicalTableScan(table=[[CATALOG, SALES, BONUS]])
> LogicalAggregate(group=[{}], agg#0=[SINGLE_VALUE($0)])
> LogicalProject(JOB=[$2])
> LogicalFilter(condition=[=($7, $cor0.DEPTNO)])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-4225) Make RelDecorrelator pluggable
[
https://issues.apache.org/jira/browse/CALCITE-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-4225.
-
Resolution: Fixed
Fixed in
[3c7e2e3|https://github.com/apache/calcite/commit/3c7e2e3f3edbf60d93ebf7c8946d1177a02d3e87]
!
> Make RelDecorrelator pluggable
> --
>
> Key: CALCITE-4225
> URL: https://issues.apache.org/jira/browse/CALCITE-4225
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.25.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {{RelDecorrelator}} is our core component that decorrelates the queries. But
> actually, the pattern it can decorrelate successfully is very limited. And it
> often causes bug because it decorrelates into a wrong plan (with non-correct
> sementics).
> When there are bugs there, the downstream project can only wait for the
> version upgrade (if it is fixed in Calcite master), or they copy the whole
> Java class and override the Calcite one which is hard to maintain.
> It would be nice if we can make the decorrelation logic pluggable. e.g. we
> can control how a RelNode was decorrelated(not a coarse-grained flag to
> turn-on/off the decorrelation).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4225) Make RelDecorrelator pluggable
[
https://issues.apache.org/jira/browse/CALCITE-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219532#comment-17219532
]
Danny Chen commented on CALCITE-4225:
-
I'm planning to merge within 24 hours ~
> Make RelDecorrelator pluggable
> --
>
> Key: CALCITE-4225
> URL: https://issues.apache.org/jira/browse/CALCITE-4225
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.25.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {{RelDecorrelator}} is our core component that decorrelates the queries. But
> actually, the pattern it can decorrelate successfully is very limited. And it
> often causes bug because it decorrelates into a wrong plan (with non-correct
> sementics).
> When there are bugs there, the downstream project can only wait for the
> version upgrade (if it is fixed in Calcite master), or they copy the whole
> Java class and override the Calcite one which is hard to maintain.
> It would be nice if we can make the decorrelation logic pluggable. e.g. we
> can control how a RelNode was decorrelated(not a coarse-grained flag to
> turn-on/off the decorrelation).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4225) Make RelDecorrelator pluggable
[
https://issues.apache.org/jira/browse/CALCITE-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218956#comment-17218956
]
Danny Chen commented on CALCITE-4225:
-
[~julianhyde] Do you think i should put the {{postDecorrelateRules}} into a
config ? Or add a method to override like in this PR ?
> Make RelDecorrelator pluggable
> --
>
> Key: CALCITE-4225
> URL: https://issues.apache.org/jira/browse/CALCITE-4225
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.25.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.27.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {{RelDecorrelator}} is our core component that decorrelates the queries. But
> actually, the pattern it can decorrelate successfully is very limited. And it
> often causes bug because it decorrelates into a wrong plan (with non-correct
> sementics).
> When there are bugs there, the downstream project can only wait for the
> version upgrade (if it is fixed in Calcite master), or they copy the whole
> Java class and override the Calcite one which is hard to maintain.
> It would be nice if we can make the decorrelation logic pluggable. e.g. we
> can control how a RelNode was decorrelated(not a coarse-grained flag to
> turn-on/off the decorrelation).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4347) Illegal use of dynamic parameter when use preparestatement
[ https://issues.apache.org/jira/browse/CALCITE-4347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17218687#comment-17218687 ] Danny Chen commented on CALCITE-4347: - Thanks for reporting this [~zhangbushi5], you can write a re-produceable case in SqlValidatorTest so that we can debug and fix. > Illegal use of dynamic parameter when use preparestatement > -- > > Key: CALCITE-4347 > URL: https://issues.apache.org/jira/browse/CALCITE-4347 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: yangzhang >Priority: Major > > hi , when query with preparestatement, validator throws exception. > here is 2 sqls: > 1、select LSTG_FORMAT_NAME > from kylin_sales > where LSTG_FORMAT_NAME=substring(?,1,6) > > 2、select LSTG_FORMAT_NAME > from kylin_sales > where LSTG_FORMAT_NAME=substring(?,?,6) > > trace is: > Caused by: org.apache.calcite.runtime.CalciteContextException: At line 4, > column 34: Illegal use of dynamic parameter > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:803) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:788) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4708) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1710) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1785) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.inferUnknownTypes(SqlValidatorImpl.java:1785) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereOrOn(SqlValidatorImpl.java:3906) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.validateWhereClause(SqlValidatorImpl.java:3898) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3224) > at > org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60) > at > org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:949) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:930) > at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:226) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:905) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:615) > at > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:576) > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:269) > at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:235) > at > org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:804) > at > org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:663) > at > org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:626) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:232) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.prepareStatement_(CalciteConnectionImpl.java:214) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4225) Make RelDecorrelator pluggable
[
https://issues.apache.org/jira/browse/CALCITE-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen updated CALCITE-4225:
Fix Version/s: 1.27.0
> Make RelDecorrelator pluggable
> --
>
> Key: CALCITE-4225
> URL: https://issues.apache.org/jira/browse/CALCITE-4225
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.25.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Fix For: 1.27.0
>
>
> {{RelDecorrelator}} is our core component that decorrelates the queries. But
> actually, the pattern it can decorrelate successfully is very limited. And it
> often causes bug because it decorrelates into a wrong plan (with non-correct
> sementics).
> When there are bugs there, the downstream project can only wait for the
> version upgrade (if it is fixed in Calcite master), or they copy the whole
> Java class and override the Calcite one which is hard to maintain.
> It would be nice if we can make the decorrelation logic pluggable. e.g. we
> can control how a RelNode was decorrelated(not a coarse-grained flag to
> turn-on/off the decorrelation).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
