[jira] [Closed] (CALCITE-5945) Forced join order SQL hint.
[ https://issues.apache.org/jira/browse/CALCITE-5945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin closed CALCITE-5945. - Resolution: Won't Fix Wrong project. > Forced join order SQL hint. > --- > > Key: CALCITE-5945 > URL: https://issues.apache.org/jira/browse/CALCITE-5945 > Project: Calcite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Major > > For the join operations, we should have several SQL hints. One of them are > forced join order hints. As an example, Oracle DB's analogue would be > 'ORDERED', 'LEADING'. Might be combined with join operation type like merge, > hash, nl like 'USE_NL', 'USE_MERGE' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5945) Forced join order SQL hint.
Vladimir Steshin created CALCITE-5945: - Summary: Forced join order SQL hint. Key: CALCITE-5945 URL: https://issues.apache.org/jira/browse/CALCITE-5945 Project: Calcite Issue Type: Task Reporter: Vladimir Steshin For the join operations, we should have several SQL hints. One of them are forced join order hints. As an example, Oracle DB's analogue would be 'ORDERED', 'LEADING'. Might be combined with join operation type like merge, hash, nl like 'USE_NL', 'USE_MERGE' -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
[
https://issues.apache.org/jira/browse/CALCITE-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754067#comment-17754067
]
Vladimir Steshin edited comment on CALCITE-5915 at 8/14/23 12:15 PM:
-
[~shenlang], thank you. I've realized what's going on. We use
{code:java}
CoreRules.FILTER_SUB_QUERY_TO_CORRELATE,
CoreRules.PROJECT_SUB_QUERY_TO_CORRELATE,
CoreRules.JOIN_SUB_QUERY_TO_CORRELATE
{code}
but we have no call of _RelDecorrelator#decorrelateQuery_. And the sub-query
transformation omits hints propagation:
{code:java}
public static RelNode RelOptUtil#propagateRelHints(RelNode originalRel, RelNode
equiv) {
if (!(originalRel instanceof Hintable)
|| ((Hintable) originalRel).getHints().size() == 0) {
// Exits here.
return equiv;
}
...
}
{code}
This happens because after the sub-queries change, hints appear below this
code's _RelNode originalRel_. It has no hints, the propagation stops. Example:
{code:java}
LogicalProject
LogicalFilter (had no hints, *propagateRelHints(RelNode, RelNode) exists*)
LogicalJoin
left: TableScan
right: LogicalAggregate
LogicalProject (has *hints to propagate* down)
LogicalFilter
LogicalTableScan (*waits for the hints*)
{code}
To me, it is a bit weird that the propagation checks current node's hints and
exists. Hints might be extracted further. Well, I just call
_propagateRelHints(RelNode, boolean)_ after that rule set. Works.
was (Author: vladsz83):
[~shenlang], thank you. I've realized what's going on. We use
{code:java}
CoreRules.FILTER_SUB_QUERY_TO_CORRELATE,
CoreRules.PROJECT_SUB_QUERY_TO_CORRELATE,
CoreRules.JOIN_SUB_QUERY_TO_CORRELATE
{code}
but we have no call of _RelDecorrelator#decorrelateQuery_. And the subquery
transformation omits hints propagation:
{code:java}
public static RelNode RelOptUtil#propagateRelHints(RelNode originalRel, RelNode
equiv) {
if (!(originalRel instanceof Hintable)
|| ((Hintable) originalRel).getHints().size() == 0) {
// Exists here.
return equiv;
}
...
}
{code}
This happens because after the subqueries change hints appear below this code's
_RelNode originalRel_. It has no hints, the propagation stops. Example:
{code:java}
LogicalProject
LogicalFilter (had no hints, *propagateRelHints(RelNode, RelNode) exists*)
LogicalJoin
left: TableScan
right: LogicalAggregate
LogicalProject (has *hints to propagate* down)
LogicalFilter
LogicalTableScan (*waits for the hints*)
{code}
To me it is a bit weird that the propagation checks current node's hints and
exists. Hints might be extracted further. Well, I just call
_propagateRelHints(RelNode, boolean)_ after that rule set. Works.
> Missing SQL hints in not-expanded subqueries.
> --
>
> Key: CALCITE-5915
> URL: https://issues.apache.org/jira/browse/CALCITE-5915
> Project: Calcite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java,
> image-2023-08-13-23-11-56-589.png
>
>
> Not sure if it is a bug becuase the query plans in this case might not be
> final and require further expanding, but the SQL hints might not be
> propagated to subqueries when SqlToRelConverter#withExpand==false. This
> happens because hints are pushed down with
> _RelOptUtil#RelHintPropagateShuttle_ and
> _RelOptUtil#SubTreeHintPropagateShuttle_ which travese through
> _RelNode#getInputs()_. But what if node is not accessible as other node’s
> input like keeping in _LogicalFilter#condition_? Then the shuttles skip such
> nodes.
> Test attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
[
https://issues.apache.org/jira/browse/CALCITE-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17754067#comment-17754067
]
Vladimir Steshin commented on CALCITE-5915:
---
[~shenlang], thank you. I've realized what's going on. We use
{code:java}
CoreRules.FILTER_SUB_QUERY_TO_CORRELATE,
CoreRules.PROJECT_SUB_QUERY_TO_CORRELATE,
CoreRules.JOIN_SUB_QUERY_TO_CORRELATE
{code}
but we have no call of _RelDecorrelator#decorrelateQuery_. And the subquery
transformation omits hints propagation:
{code:java}
public static RelNode RelOptUtil#propagateRelHints(RelNode originalRel, RelNode
equiv) {
if (!(originalRel instanceof Hintable)
|| ((Hintable) originalRel).getHints().size() == 0) {
// Exists here.
return equiv;
}
...
}
{code}
This happens because after the subqueries change hints appear below this code's
_RelNode originalRel_. It has no hints, the propagation stops. Example:
{code:java}
LogicalProject
LogicalFilter (had no hints, *propagateRelHints(RelNode, RelNode) exists*)
LogicalJoin
left: TableScan
right: LogicalAggregate
LogicalProject (has *hints to propagate* down)
LogicalFilter
LogicalTableScan (*waits for the hints*)
{code}
To me it is a bit weird that the propagation checks current node's hints and
exists. Hints might be extracted further. Well, I just call
_propagateRelHints(RelNode, boolean)_ after that rule set. Works.
> Missing SQL hints in not-expanded subqueries.
> --
>
> Key: CALCITE-5915
> URL: https://issues.apache.org/jira/browse/CALCITE-5915
> Project: Calcite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java,
> image-2023-08-13-23-11-56-589.png
>
>
> Not sure if it is a bug becuase the query plans in this case might not be
> final and require further expanding, but the SQL hints might not be
> propagated to subqueries when SqlToRelConverter#withExpand==false. This
> happens because hints are pushed down with
> _RelOptUtil#RelHintPropagateShuttle_ and
> _RelOptUtil#SubTreeHintPropagateShuttle_ which travese through
> _RelNode#getInputs()_. But what if node is not accessible as other node’s
> input like keeping in _LogicalFilter#condition_? Then the shuttles skip such
> nodes.
> Test attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
[ https://issues.apache.org/jira/browse/CALCITE-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated CALCITE-5915: -- Description: Not sure if it is a bug becuase the query plans in this case might not be final and require further expanding, but the SQL hints might not be propagated to subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ and _RelOptUtil#SubTreeHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like keeping in _LogicalFilter#condition_? Then the shuttles skip such nodes. Test attached. was: Not sure if it is a bug becuase the query plans in this case might not be final and require further expanding, but the SQL hints might not be propagated to subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ and _RelOptUtil#SubTreeHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like keeping in _LogicalFilter#condition_? Then the shuttle skips such nodes. Test attached. > Missing SQL hints in not-expanded subqueries. > -- > > Key: CALCITE-5915 > URL: https://issues.apache.org/jira/browse/CALCITE-5915 > Project: Calcite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Minor > Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java > > > Not sure if it is a bug becuase the query plans in this case might not be > final and require further expanding, but the SQL hints might not be > propagated to subqueries when SqlToRelConverter#withExpand==false. This > happens because hints are pushed down with > _RelOptUtil#RelHintPropagateShuttle_ and > _RelOptUtil#SubTreeHintPropagateShuttle_ which travese through > _RelNode#getInputs()_. But what if node is not accessible as other node’s > input like keeping in _LogicalFilter#condition_? Then the shuttles skip such > nodes. > Test attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
[ https://issues.apache.org/jira/browse/CALCITE-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated CALCITE-5915: -- Description: Not sure if it is a bug becuase the query plans in this case might not be final and require further expanding, but the SQL hints might not be propagated to subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ and _RelOptUtil#SubTreeHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like keeping in _LogicalFilter#condition_? Then the shuttle skips such nodes. Test attached. was: Not sure if it is a bug becuase the query plans in this case might not be final and require further expanding, but the SQL hints might not be propagated to subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like keeping in _LogicalFilter#condition_? Then the shuttle skips such nodes. Test attached. > Missing SQL hints in not-expanded subqueries. > -- > > Key: CALCITE-5915 > URL: https://issues.apache.org/jira/browse/CALCITE-5915 > Project: Calcite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Minor > Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java > > > Not sure if it is a bug becuase the query plans in this case might not be > final and require further expanding, but the SQL hints might not be > propagated to subqueries when SqlToRelConverter#withExpand==false. This > happens because hints are pushed down with > _RelOptUtil#RelHintPropagateShuttle_ and > _RelOptUtil#SubTreeHintPropagateShuttle_ which travese through > _RelNode#getInputs()_. But what if node is not accessible as other node’s > input like keeping in _LogicalFilter#condition_? Then the shuttle skips such > nodes. > Test attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
[ https://issues.apache.org/jira/browse/CALCITE-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated CALCITE-5915: -- Description: Not sure if it is a bug becuase the query plans in this case might not be final and require further expanding, but the SQL hints might not be propagated to subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like keeping in _LogicalFilter#condition_? Then the shuttle skips such nodes. Test attached. was: Not sure if it is a bug becuase the query plans in this case might not be final and require further expanding, but the SQL hints might not be propagated to subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like keeping in _LogicalFilter#condition_? Then the shuttle skips such nodes. I found tah may happen in qubqueries. Test attached. > Missing SQL hints in not-expanded subqueries. > -- > > Key: CALCITE-5915 > URL: https://issues.apache.org/jira/browse/CALCITE-5915 > Project: Calcite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Minor > Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java > > > Not sure if it is a bug becuase the query plans in this case might not be > final and require further expanding, but the SQL hints might not be > propagated to subqueries when SqlToRelConverter#withExpand==false. This > happens because hints are pushed down with > _RelOptUtil#RelHintPropagateShuttle_ which travese through > _RelNode#getInputs()_. But what if node is not accessible as other node’s > input like keeping in _LogicalFilter#condition_? Then the shuttle skips such > nodes. > Test attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
[ https://issues.apache.org/jira/browse/CALCITE-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated CALCITE-5915: -- Description: Not sure if it is a bug becuase the query plans in this case might not be final and require further expanding, but the SQL hints might not be propagated to subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like keeping in _LogicalFilter#condition_? Then the shuttle skips such nodes. I found tah may happen in qubqueries. Test attached. was: Not sure if it is a bug becuase the query plans in this case might not be final and require further expanding, but the SQL hints might not be propagated to subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like _LogicalFilter#condition_? Then the shuttle skips such nodes. I found tah may happen in qubqueries. Test attached. > Missing SQL hints in not-expanded subqueries. > -- > > Key: CALCITE-5915 > URL: https://issues.apache.org/jira/browse/CALCITE-5915 > Project: Calcite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Minor > Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java > > > Not sure if it is a bug becuase the query plans in this case might not be > final and require further expanding, but the SQL hints might not be > propagated to subqueries when SqlToRelConverter#withExpand==false. This > happens because hints are pushed down with > _RelOptUtil#RelHintPropagateShuttle_ which travese through > _RelNode#getInputs()_. But what if node is not accessible as other node’s > input like keeping in _LogicalFilter#condition_? Then the shuttle skips such > nodes. I found tah may happen in qubqueries. > Test attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
[ https://issues.apache.org/jira/browse/CALCITE-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated CALCITE-5915: -- Description: Not sure if it is a bug becuase the query plans in this case might not be final and require further expanding, but the SQL hints might not be propagated to subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like _LogicalFilter#condition_? Then the shuttle skips such nodes. I found tah may happen in qubqueries. Test attached. was: The SQL hints might not be propagated in decorrelated subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like _LogicalFilter#condition_? Then the shuttle skips such nodes. I found tah may happen in qubqueries. Test attached. > Missing SQL hints in not-expanded subqueries. > -- > > Key: CALCITE-5915 > URL: https://issues.apache.org/jira/browse/CALCITE-5915 > Project: Calcite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Minor > Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java > > > Not sure if it is a bug becuase the query plans in this case might not be > final and require further expanding, but the SQL hints might not be > propagated to subqueries when SqlToRelConverter#withExpand==false. This > happens because hints are pushed down with > _RelOptUtil#RelHintPropagateShuttle_ which travese through > _RelNode#getInputs()_. But what if node is not accessible as other node’s > input like _LogicalFilter#condition_? Then the shuttle skips such nodes. I > found tah may happen in qubqueries. > Test attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
[ https://issues.apache.org/jira/browse/CALCITE-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated CALCITE-5915: -- Attachment: SqlHintsInSubqueriesWithDisabledExpanding.java > Missing SQL hints in not-expanded subqueries. > -- > > Key: CALCITE-5915 > URL: https://issues.apache.org/jira/browse/CALCITE-5915 > Project: Calcite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Minor > Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java > > > The SQL hints might not be propagated in decorrelated subqueries when > SqlToRelConverter#withExpand==false. This happens because hints are pushed > down with _RelOptUtil#RelHintPropagateShuttle_ which travese through > _RelNode#getInputs()_. But what if node is not accessible as other node’s > input like _LogicalFilter#condition_? Then the shuttle skips such nodes. I > found tah may happen in qubqueries. > Test attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
[ https://issues.apache.org/jira/browse/CALCITE-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated CALCITE-5915: -- Attachment: (was: SqlHintsInSubqueriesWithDisabledExpanding.java) > Missing SQL hints in not-expanded subqueries. > -- > > Key: CALCITE-5915 > URL: https://issues.apache.org/jira/browse/CALCITE-5915 > Project: Calcite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Minor > Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java > > > The SQL hints might not be propagated in decorrelated subqueries when > SqlToRelConverter#withExpand==false. This happens because hints are pushed > down with _RelOptUtil#RelHintPropagateShuttle_ which travese through > _RelNode#getInputs()_. But what if node is not accessible as other node’s > input like _LogicalFilter#condition_? Then the shuttle skips such nodes. I > found tah may happen in qubqueries. > Test attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
Vladimir Steshin created CALCITE-5915: - Summary: Missing SQL hints in not-expanded subqueries. Key: CALCITE-5915 URL: https://issues.apache.org/jira/browse/CALCITE-5915 Project: Calcite Issue Type: Bug Reporter: Vladimir Steshin Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java The SQL hints might not be propagated in decorrelated subqueries when SqlToRelConverter#withExpand==false. This happens because hints are pushed down with _RelOptUtil#RelHintPropagateShuttle_ which travese through _RelNode#getInputs()_. But what if node is not accessible as other node’s input like _LogicalFilter#condition_? Then the shuttle skips such nodes. I found tah may happen in qubqueries. Test attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5915) Missing SQL hints in not-expanded subqueries.
[ https://issues.apache.org/jira/browse/CALCITE-5915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated CALCITE-5915: -- Attachment: SqlHintsInSubqueriesWithDisabledExpanding.java > Missing SQL hints in not-expanded subqueries. > -- > > Key: CALCITE-5915 > URL: https://issues.apache.org/jira/browse/CALCITE-5915 > Project: Calcite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Minor > Attachments: SqlHintsInSubqueriesWithDisabledExpanding.java > > > The SQL hints might not be propagated in decorrelated subqueries when > SqlToRelConverter#withExpand==false. This happens because hints are pushed > down with _RelOptUtil#RelHintPropagateShuttle_ which travese through > _RelNode#getInputs()_. But what if node is not accessible as other node’s > input like _LogicalFilter#condition_? Then the shuttle skips such nodes. I > found tah may happen in qubqueries. > Test attached. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-5154) Boolean clause is not recognized as boolean in Join-On's subquery.
[
https://issues.apache.org/jira/browse/CALCITE-5154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-5154:
--
Description:
Not the best example, I believe, but shows strange type checking:
{code:sql}
SELECT d.deptno FROM dept d INNER JOIN dept d2 ON (SELECT d.deptno=d2.deptno)
{code}
Or simplier
{code:sql}
SELECT d.deptno FROM dept d INNER JOIN dept d2 ON (SELECT d.deptno=1)
{code}
Works in Postgres at least. The problem is that RelDataType (isStruct() ==
true) of single boolean is not considered as Boolean. Whereas the condition
actually says true and should work.
{code:java}
protected void validateWhereOrOn(
SqlValidatorScope scope,
SqlNode condition,
String clause) {
validateNoAggs(aggOrOverOrGroupFinder, condition, clause);
inferUnknownTypes(
booleanType,
scope,
condition);
condition.validate(this, scope);
final RelDataType type = deriveType(scope, condition);
if (!SqlTypeUtil.inBooleanFamily(type)) {
throw newValidationError(condition, RESOURCE.condMustBeBoolean(clause));
}
}
{code}
I’ve tried to re-implement validateWhereOrOn(), or validateSelectList(), or
deriveType(). To derive/cast type of namespace/condition to
BasicSqlType(Boolean). But even for the recognized bool-clause, Calcite could
fail further on different namespaces:
{code:java}
java.lang.AssertionError: All correlation variables should resolve to the same
namespace. Prev
ns=org.apache.calcite.sql.validate.IdentifierNamespace@3765a411, new
ns=org.apache.calcite.sql.validate.IdentifierNamespace@58593307
at
org.apache.calcite.sql2rel.SqlToRelConverter.getCorrelationUse(SqlToRelConverter.java:2867)
at
org.apache.calcite.sql2rel.SqlToRelConverter.createJoin(SqlToRelConverter.java:2777)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.register(SqlToRelConverter.java:4710)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.reRegister(SqlToRelConverter.java:4765)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertOnCondition(SqlToRelConverter.java:3112)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertJoin(SqlToRelConverter.java:3034)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2245)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2133)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:683)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3589)
{code}
Or, depending on the query, struct type could be strictly required instead of
derived Boolean-BasicSqlType:
{code:java}
public static final SqlOperandTypeChecker RECORD_TO_SCALAR =
new SqlSingleOperandTypeChecker() {
@Override public boolean checkSingleOperandType(
SqlCallBinding callBinding,
SqlNode node,
int iFormalOperand,
boolean throwOnFailure) {
assert 0 == iFormalOperand;
RelDataType type = SqlTypeUtil.deriveType(callBinding, node);
boolean validationError = false;
if (!type.isStruct()) {
validationError = true;
} else if (type.getFieldList().size() != 1) {
validationError = true;
}
if (validationError && throwOnFailure) {
throw callBinding.newValidationSignatureError();
…
{code}
So, the type derivation seems not to be a solution. However, maybe there should
be a way to re-implement, inherit or extend somehow this type checking. Like
moving
{code:java}
SqlTypeUtil.inBooleanFamily()
{code}
into SqlValidator, or to TypeCoercion, or to RelDataTypeSystem and making it
protected.
was:
Not the best example, I believe, but shows strange type checking:
{code:sql}
SELECT d.deptno FROM dept d INNER JOIN dept d2 ON (SELECT d.deptno=d2.deptno)
{code}
Or simplier
{code:sql}
SELECT d.deptno FROM dept d INNER JOIN dept d2 ON (SELECT d.deptno=1)
{code}
Works in Postgres at least. The problem is that RelDataType (isStruct() ==
true) of single boolean is not considered as Boolean. Whereas the condition
actually says true and should work.
{code:java}
protected void validateWhereOrOn(
SqlValidatorScope scope,
SqlNode condition,
String clause) {
validateNoAggs(aggOrOverOrGroupFinder, condition, clause);
inferUnknownTypes(
booleanType,
scope,
condition);
condition.validate(this, scope);
final RelDataType type = deriveType(scope, condition);
if (!SqlTypeUtil.inBooleanFamily(type)) {
throw newValidationError(condition, RESOURCE.condMustBeBoolean(clause));
}
}
{code}
I’ve tried to re-implement
[jira] [Updated] (CALCITE-5154) Boolean clause is not recognized as boolean in Join-On's subquery.
[
https://issues.apache.org/jira/browse/CALCITE-5154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-5154:
--
Description:
Not the best example, I believe, but shows strange type checking:
{code:sql}
SELECT d.deptno FROM dept d INNER JOIN dept d2 ON (SELECT d.deptno=d2.deptno)
{code}
Or simplier
{code:sql}
SELECT d.deptno FROM dept d INNER JOIN dept d2 ON (SELECT d.deptno=1)
{code}
Works in Postgres at least. The problem is that RelDataType (isStruct() ==
true) of single boolean is not considered as Boolean. Whereas the condition
actually says true and should work.
{code:java}
protected void validateWhereOrOn(
SqlValidatorScope scope,
SqlNode condition,
String clause) {
validateNoAggs(aggOrOverOrGroupFinder, condition, clause);
inferUnknownTypes(
booleanType,
scope,
condition);
condition.validate(this, scope);
final RelDataType type = deriveType(scope, condition);
if (!SqlTypeUtil.inBooleanFamily(type)) {
throw newValidationError(condition, RESOURCE.condMustBeBoolean(clause));
}
}
{code}
I’ve tried to re-implement validateWhereOrOn(), or validateSelectList(), or
deriveType(). To derive/cast type of namespace/condition to
BasicSqlType(Boolean). But even for the recognized bool-clause, Calcite could
fail further on different namespaces:
{code:java}
java.lang.AssertionError: All correlation variables should resolve to the same
namespace. Prev
ns=org.apache.calcite.sql.validate.IdentifierNamespace@3765a411, new
ns=org.apache.calcite.sql.validate.IdentifierNamespace@58593307
at
org.apache.calcite.sql2rel.SqlToRelConverter.getCorrelationUse(SqlToRelConverter.java:2867)
at
org.apache.calcite.sql2rel.SqlToRelConverter.createJoin(SqlToRelConverter.java:2777)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.register(SqlToRelConverter.java:4710)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.reRegister(SqlToRelConverter.java:4765)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertOnCondition(SqlToRelConverter.java:3112)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertJoin(SqlToRelConverter.java:3034)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2245)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2133)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:683)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3589)
{code}
Or, depending on the query, struct type could be strictly required instead of
derived Boolean-BasicSqlType:
{code:java}
public static final SqlOperandTypeChecker RECORD_TO_SCALAR =
new SqlSingleOperandTypeChecker() {
@Override public boolean checkSingleOperandType(
SqlCallBinding callBinding,
SqlNode node,
int iFormalOperand,
boolean throwOnFailure) {
assert 0 == iFormalOperand;
RelDataType type = SqlTypeUtil.deriveType(callBinding, node);
boolean validationError = false;
if (!type.isStruct()) {
validationError = true;
} else if (type.getFieldList().size() != 1) {
validationError = true;
}
if (validationError && throwOnFailure) {
throw callBinding.newValidationSignatureError();
…
{code}
So, the type derivation seems not to be a solution.However, but there should be
a way to re-implement, inherit or extend somehow this type checking. Like
moving
{code:java}
SqlTypeUtil.inBooleanFamily()
{code}
into SqlValidator, or to TypeCoercion, or to RelDataTypeSystem and making it
protected.
was:
Not the best example, I believe, but shows strange type checking:
{code:sql}
SELECT d.deptno FROM dept d INNER JOIN dept d2 ON (SELECT d.deptno=d2.deptno)
{code}
Or simplier
{code:sql}
SELECT d.deptno FROM dept d INNER JOIN dept d2 ON (SELECT d.deptno=1)
{code}
Works in Postgres at least. The problem is that RelDataType (isStruct() ==
true) of single boolean is not considered as Boolean. Whereas the condition
actually says true and should work.
{code:java}
protected void validateWhereOrOn(
SqlValidatorScope scope,
SqlNode condition,
String clause) {
validateNoAggs(aggOrOverOrGroupFinder, condition, clause);
inferUnknownTypes(
booleanType,
scope,
condition);
condition.validate(this, scope);
final RelDataType type = deriveType(scope, condition);
if (!SqlTypeUtil.inBooleanFamily(type)) {
throw newValidationError(condition, RESOURCE.condMustBeBoolean(clause));
}
}
{code}
I’ve tried to re-implement
[jira] [Created] (CALCITE-5154) Boolean clause is not recognized as boolean in Join-On's subquery.
Vladimir Steshin created CALCITE-5154:
-
Summary: Boolean clause is not recognized as boolean in Join-On's
subquery.
Key: CALCITE-5154
URL: https://issues.apache.org/jira/browse/CALCITE-5154
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.30.0
Reporter: Vladimir Steshin
Not the best example, I believe, but shows strange type checking:
{code:sql}
SELECT d.deptno FROM dept d INNER JOIN dept d2 ON (SELECT d.deptno=d2.deptno)
{code}
Or simplier
{code:sql}
SELECT d.deptno FROM dept d INNER JOIN dept d2 ON (SELECT d.deptno=1)
{code}
Works in Postgres at least. The problem is that RelDataType (isStruct() ==
true) of single boolean is not considered as Boolean. Whereas the condition
actually says true and should work.
{code:java}
protected void validateWhereOrOn(
SqlValidatorScope scope,
SqlNode condition,
String clause) {
validateNoAggs(aggOrOverOrGroupFinder, condition, clause);
inferUnknownTypes(
booleanType,
scope,
condition);
condition.validate(this, scope);
final RelDataType type = deriveType(scope, condition);
if (!SqlTypeUtil.inBooleanFamily(type)) {
throw newValidationError(condition, RESOURCE.condMustBeBoolean(clause));
}
}
{code}
I’ve tried to re-implement validateWhereOrOn(), or validateSelectList(), or
deriveType(). To derive/cast type of namespace/condition to
BasicSqlType(Boolean). But even for the recognized bool-clause, Calcite could
fail further on different namespaces:
{code:java}
java.lang.AssertionError: All correlation variables should resolve to the same
namespace. Prev
ns=org.apache.calcite.sql.validate.IdentifierNamespace@3765a411, new
ns=org.apache.calcite.sql.validate.IdentifierNamespace@58593307
at
org.apache.calcite.sql2rel.SqlToRelConverter.getCorrelationUse(SqlToRelConverter.java:2867)
at
org.apache.calcite.sql2rel.SqlToRelConverter.createJoin(SqlToRelConverter.java:2777)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.register(SqlToRelConverter.java:4710)
at
org.apache.calcite.sql2rel.SqlToRelConverter$Blackboard.reRegister(SqlToRelConverter.java:4765)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertOnCondition(SqlToRelConverter.java:3112)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertJoin(SqlToRelConverter.java:3034)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2245)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertFrom(SqlToRelConverter.java:2133)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelectImpl(SqlToRelConverter.java:683)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertSelect(SqlToRelConverter.java:664)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3589)
{code}
Or, depending on the query, struct type could be strictly required instead of
derived Boolean-BasicSqlType:
{code:java}
public static final SqlOperandTypeChecker RECORD_TO_SCALAR =
new SqlSingleOperandTypeChecker() {
@Override public boolean checkSingleOperandType(
SqlCallBinding callBinding,
SqlNode node,
int iFormalOperand,
boolean throwOnFailure) {
assert 0 == iFormalOperand;
RelDataType type = SqlTypeUtil.deriveType(callBinding, node);
boolean validationError = false;
if (!type.isStruct()) {
validationError = true;
} else if (type.getFieldList().size() != 1) {
validationError = true;
}
if (validationError && throwOnFailure) {
throw callBinding.newValidationSignatureError();
…
{code}
So, the type derivation seems not to be a solution. Not sure, but there should
be a way to re-implement, inherit or extend somehow this type checking. Like
moving
{code:java}
SqlTypeUtil.inBooleanFamily()
{code}
into SqlValidator, or to TypeCoercion, or to RelDataTypeSystem and making it
protected.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (CALCITE-4943) Type mismatch in Project / HepPlanner: INTEGER to JavaType(int)
[
https://issues.apache.org/jira/browse/CALCITE-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461224#comment-17461224
]
Vladimir Steshin commented on CALCITE-4943:
---
[~julianhyde], 1.29
> Type mismatch in Project / HepPlanner: INTEGER to JavaType(int)
> ---
>
> Key: CALCITE-4943
> URL: https://issues.apache.org/jira/browse/CALCITE-4943
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.29.0
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: sub-query
>
> Found by JdbcTest.
> Test query:
> {code:sql}
> CalciteAssert.hr()
> .query("select (select (select t.\"empid\")) from \"hr\".\"emps\" t")
> .returnsCount(4);
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: type mismatch:
> ref:
> JavaType(int) NOT NULL
> input:
> INTEGER NOT NULL
> {code}
> Stacktrace:
> {code:java}
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
> at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:2211)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:129)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at org.apache.calcite.rel.core.Project.isValid(Project.java:219)
> at org.apache.calcite.rel.core.Project.(Project.java:98)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:69)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:126)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:114)
> at
> org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:178)
> at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:2020)
> at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1792)
> at
> org.apache.calcite.tools.RelBuilder.projectNamed(RelBuilder.java:2083)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.projectJoinOutputWithNullability(RelDecorrelator.java:1445)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.access$900(RelDecorrelator.java:147)
> at
> org.apache.calcite.sql2rel.RelDecorrelator$RemoveCorrelationForScalarProjectRule.onMatch(RelDecorrelator.java:2149)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:343)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:251)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:130)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.removeCorrelationViaRule(RelDecorrelator.java:378)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:221)
> at
> org.apache.calcite.tools.Programs$DecorrelateProgram.run(Programs.java:361)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:177)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:312)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-685) Correlated scalar sub-query in SELECT clause throws
[
https://issues.apache.org/jira/browse/CALCITE-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461108#comment-17461108
]
Vladimir Steshin commented on CALCITE-685:
--
If I'm correct, one should look into LogicalAggregate and/or LogicalProject.
Working plan:
{code:java}
LogicalProject(department_id=[$7], EXPR$1=[$SCALAR_QUERY({
LogicalProject(EXPR$0=[1])
LogicalFilter(condition=[=($cor0.department_id, -($7, 5000))])
LogicalTableScan(table=[[foodmart2, employee]])
})])
LogicalTableScan(table=[[foodmart2, employee]])
{code}
Malfunction:
{code:java}
LogicalProject(department_id=[$0], EXPR$1=[$SCALAR_QUERY({
LogicalProject(EXPR$0=[1])
LogicalFilter(condition=[=($cor0.department_id, $7)])
LogicalTableScan(table=[[foodmart2, employee]])
})])
LogicalAggregate(group=[{0}])
LogicalProject(department_id=[$7])
LogicalTableScan(table=[[foodmart2, employee]])
{code}
The correlate being created on TableScan gets as 'left' full rowType holding
the required columns (Correlate.requiredColumns). Otherwise, Correlate receives
only 1 and other column.
> Correlated scalar sub-query in SELECT clause throws
> ---
>
> Key: CALCITE-685
> URL: https://issues.apache.org/jira/browse/CALCITE-685
> Project: Calcite
> Issue Type: Bug
>Reporter: Jinfeng Ni
>Priority: Major
> Labels: sub-query
>
> For the following query, where a correlated scalar subquery is put in select
> list, Calcite will hit NPE in RelDecorrelator.
> {code}
> select e.department_id, sum(e.employee_id),
>( select sum(e2.employee_id)
> from employee e2
> where e.department_id = e2.department_id
>)
> from employee e
> group by e.department_id;
> {code}
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.sql2rel.RelDecorrelator.createValueGenerator(RelDecorrelator.java:733)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateInputWithValueGenerator(RelDecorrelator.java:842)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:902)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:256)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:213)
> at
> org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:476)
> at
> org.apache.calcite.sql2rel.RelDecorrelator$DecorrelateRelVisitor.visit(RelDecorrelator.java:1420)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> .
> {code}
> Here is the unit test case I used to re-produce this problem in JdbcTest.java
> {code}
> @Test public void testCorreScalarSubQInSelect()
> throws ClassNotFoundException, SQLException {
> String query = "select e.department_id, sum(e.employee_id),\n"
> + " ( select sum(e2.employee_id)\n"
> + " from employee e2\n"
> + " where e.department_id = e2.department_id\n"
> + " )\n"
> + " from employee e\n"
> + " group by e.department_id\n";
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .with(Lex.JAVA)
> .query(query)
> .returnsCount(0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4945) Runtime compilation fails on subquery.
[
https://issues.apache.org/jira/browse/CALCITE-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4945:
--
Summary: Runtime compilation fails on subquery. (was: Compilation failes
on subquery)
> Runtime compilation fails on subquery.
> --
>
> Key: CALCITE-4945
> URL: https://issues.apache.org/jira/browse/CALCITE-4945
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.29.0
>Reporter: Vladimir Steshin
>Priority: Major
>
> While researching CALCITE-685 (calcite 1.29, master branch), I met an
> calcite-runtime compilation error.
> Request example:
> {code:sql}
> select e.department_id, (select 1 from employee e2 where e.department_id =
> -100) from employee e;
> {code}
> Stacktrace:
> {code:java}
> 2021-12-16 21:42:38,032 [ForkJoinPool-1-worker-9] INFO - open start - state
> modified
> 2021-12-16 21:42:43,612 [ForkJoinPool-1-worker-9] INFO - Checkpoint start
> 2021-12-16 21:42:43,613 [ForkJoinPool-1-worker-9] INFO - Checkpoint end -
> txts: 279
> Error while executing SQL "select e.department_id,
>( select e2.employee_id
> from employee e2
> where e.department_id = 1000
>)
> from employee e
> ": Error while compiling generated Java code:
> public static class Record2_0 implements java.io.Serializable {
> public boolean f0;
> public int f1;
> public Record2_0() {}
> public boolean equals(Object o) {
> if (this == o) {
> return true;
> }
> if (!(o instanceof Record2_0)) {
> return false;
> }
> return this.f0 == ((Record2_0) o).f0 && this.f1 == ((Record2_0) o).f1;
> }
> public int hashCode() {
> int h = 0;
> h = org.apache.calcite.runtime.Utilities.hash(h, this.f0);
> h = org.apache.calcite.runtime.Utilities.hash(h, this.f1);
> return h;
> }
> public int compareTo(Record2_0 that) {
> int c;
> c = org.apache.calcite.runtime.Utilities.compare(this.f0, that.f0);
> if (c != 0) {
> return c;
> }
> c = org.apache.calcite.runtime.Utilities.compare(this.f1, that.f1);
> if (c != 0) {
> return c;
> }
> return 0;
> }
> public String toString() {
> return "{f0=" + this.f0 + ", f1=" + this.f1 + "}";
> }
> }
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
> "employee").asEnumerable();
> final org.apache.calcite.linq4j.AbstractEnumerable child = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator =
> _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> final Object[] current = (Object[]) inputEnumerator.current();
> return new Object[] {
> current[0],
> current[7],
> org.apache.calcite.runtime.SqlFunctions.toInt(current[7]) ==
> 1000};
> }
> };
> }
> };
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable0 =
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
> "employee").asEnumerable();
> final org.apache.calcite.linq4j.AbstractEnumerable left0 = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator =
> _inputEnumerable0.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> return org.apache.calcite.runtime.SqlFunctions.toInt(((Object[])
> inputEnumerator.current())[0]);
> }
> };
> }
> };
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable00 =
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
>
[jira] [Updated] (CALCITE-4945) Compilation failes on subquery
[
https://issues.apache.org/jira/browse/CALCITE-4945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4945:
--
Affects Version/s: 1.29.0
> Compilation failes on subquery
> --
>
> Key: CALCITE-4945
> URL: https://issues.apache.org/jira/browse/CALCITE-4945
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.29.0
>Reporter: Vladimir Steshin
>Priority: Major
>
> While researching CALCITE-685 (calcite 1.29, master branch), I met an
> calcite-runtime compilation error.
> Request example:
> {code:sql}
> select e.department_id, (select 1 from employee e2 where e.department_id =
> -100) from employee e;
> {code}
> Stacktrace:
> {code:java}
> 2021-12-16 21:42:38,032 [ForkJoinPool-1-worker-9] INFO - open start - state
> modified
> 2021-12-16 21:42:43,612 [ForkJoinPool-1-worker-9] INFO - Checkpoint start
> 2021-12-16 21:42:43,613 [ForkJoinPool-1-worker-9] INFO - Checkpoint end -
> txts: 279
> Error while executing SQL "select e.department_id,
>( select e2.employee_id
> from employee e2
> where e.department_id = 1000
>)
> from employee e
> ": Error while compiling generated Java code:
> public static class Record2_0 implements java.io.Serializable {
> public boolean f0;
> public int f1;
> public Record2_0() {}
> public boolean equals(Object o) {
> if (this == o) {
> return true;
> }
> if (!(o instanceof Record2_0)) {
> return false;
> }
> return this.f0 == ((Record2_0) o).f0 && this.f1 == ((Record2_0) o).f1;
> }
> public int hashCode() {
> int h = 0;
> h = org.apache.calcite.runtime.Utilities.hash(h, this.f0);
> h = org.apache.calcite.runtime.Utilities.hash(h, this.f1);
> return h;
> }
> public int compareTo(Record2_0 that) {
> int c;
> c = org.apache.calcite.runtime.Utilities.compare(this.f0, that.f0);
> if (c != 0) {
> return c;
> }
> c = org.apache.calcite.runtime.Utilities.compare(this.f1, that.f1);
> if (c != 0) {
> return c;
> }
> return 0;
> }
> public String toString() {
> return "{f0=" + this.f0 + ", f1=" + this.f1 + "}";
> }
> }
> public org.apache.calcite.linq4j.Enumerable bind(final
> org.apache.calcite.DataContext root) {
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
> "employee").asEnumerable();
> final org.apache.calcite.linq4j.AbstractEnumerable child = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator =
> _inputEnumerable.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> final Object[] current = (Object[]) inputEnumerator.current();
> return new Object[] {
> current[0],
> current[7],
> org.apache.calcite.runtime.SqlFunctions.toInt(current[7]) ==
> 1000};
> }
> };
> }
> };
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable0 =
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
> "employee").asEnumerable();
> final org.apache.calcite.linq4j.AbstractEnumerable left0 = new
> org.apache.calcite.linq4j.AbstractEnumerable(){
> public org.apache.calcite.linq4j.Enumerator enumerator() {
> return new org.apache.calcite.linq4j.Enumerator(){
> public final org.apache.calcite.linq4j.Enumerator inputEnumerator =
> _inputEnumerable0.enumerator();
> public void reset() {
> inputEnumerator.reset();
> }
> public boolean moveNext() {
> return inputEnumerator.moveNext();
> }
> public void close() {
> inputEnumerator.close();
> }
> public Object current() {
> return org.apache.calcite.runtime.SqlFunctions.toInt(((Object[])
> inputEnumerator.current())[0]);
> }
> };
> }
> };
> final org.apache.calcite.linq4j.Enumerable _inputEnumerable00 =
> org.apache.calcite.schema.Schemas.queryable(root,
> root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
> "employee").asEnumerable();
> final org.apache.calcite.linq4j.AbstractEnumerable child0 = new
>
[jira] [Created] (CALCITE-4945) Compilation failes on subquery
Vladimir Steshin created CALCITE-4945:
-
Summary: Compilation failes on subquery
Key: CALCITE-4945
URL: https://issues.apache.org/jira/browse/CALCITE-4945
Project: Calcite
Issue Type: Bug
Reporter: Vladimir Steshin
While researching CALCITE-685 (calcite 1.29, master branch), I met an
calcite-runtime compilation error.
Request example:
{code:sql}
select e.department_id, (select 1 from employee e2 where e.department_id =
-100) from employee e;
{code}
Stacktrace:
{code:java}
2021-12-16 21:42:38,032 [ForkJoinPool-1-worker-9] INFO - open start - state
modified
2021-12-16 21:42:43,612 [ForkJoinPool-1-worker-9] INFO - Checkpoint start
2021-12-16 21:42:43,613 [ForkJoinPool-1-worker-9] INFO - Checkpoint end -
txts: 279
Error while executing SQL "select e.department_id,
( select e2.employee_id
from employee e2
where e.department_id = 1000
)
from employee e
": Error while compiling generated Java code:
public static class Record2_0 implements java.io.Serializable {
public boolean f0;
public int f1;
public Record2_0() {}
public boolean equals(Object o) {
if (this == o) {
return true;
}
if (!(o instanceof Record2_0)) {
return false;
}
return this.f0 == ((Record2_0) o).f0 && this.f1 == ((Record2_0) o).f1;
}
public int hashCode() {
int h = 0;
h = org.apache.calcite.runtime.Utilities.hash(h, this.f0);
h = org.apache.calcite.runtime.Utilities.hash(h, this.f1);
return h;
}
public int compareTo(Record2_0 that) {
int c;
c = org.apache.calcite.runtime.Utilities.compare(this.f0, that.f0);
if (c != 0) {
return c;
}
c = org.apache.calcite.runtime.Utilities.compare(this.f1, that.f1);
if (c != 0) {
return c;
}
return 0;
}
public String toString() {
return "{f0=" + this.f0 + ", f1=" + this.f1 + "}";
}
}
public org.apache.calcite.linq4j.Enumerable bind(final
org.apache.calcite.DataContext root) {
final org.apache.calcite.linq4j.Enumerable _inputEnumerable =
org.apache.calcite.schema.Schemas.queryable(root,
root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
"employee").asEnumerable();
final org.apache.calcite.linq4j.AbstractEnumerable child = new
org.apache.calcite.linq4j.AbstractEnumerable(){
public org.apache.calcite.linq4j.Enumerator enumerator() {
return new org.apache.calcite.linq4j.Enumerator(){
public final org.apache.calcite.linq4j.Enumerator inputEnumerator =
_inputEnumerable.enumerator();
public void reset() {
inputEnumerator.reset();
}
public boolean moveNext() {
return inputEnumerator.moveNext();
}
public void close() {
inputEnumerator.close();
}
public Object current() {
final Object[] current = (Object[]) inputEnumerator.current();
return new Object[] {
current[0],
current[7],
org.apache.calcite.runtime.SqlFunctions.toInt(current[7]) ==
1000};
}
};
}
};
final org.apache.calcite.linq4j.Enumerable _inputEnumerable0 =
org.apache.calcite.schema.Schemas.queryable(root,
root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
"employee").asEnumerable();
final org.apache.calcite.linq4j.AbstractEnumerable left0 = new
org.apache.calcite.linq4j.AbstractEnumerable(){
public org.apache.calcite.linq4j.Enumerator enumerator() {
return new org.apache.calcite.linq4j.Enumerator(){
public final org.apache.calcite.linq4j.Enumerator inputEnumerator =
_inputEnumerable0.enumerator();
public void reset() {
inputEnumerator.reset();
}
public boolean moveNext() {
return inputEnumerator.moveNext();
}
public void close() {
inputEnumerator.close();
}
public Object current() {
return org.apache.calcite.runtime.SqlFunctions.toInt(((Object[])
inputEnumerator.current())[0]);
}
};
}
};
final org.apache.calcite.linq4j.Enumerable _inputEnumerable00 =
org.apache.calcite.schema.Schemas.queryable(root,
root.getRootSchema().getSubSchema("foodmart2"), java.lang.Object[].class,
"employee").asEnumerable();
final org.apache.calcite.linq4j.AbstractEnumerable child0 = new
org.apache.calcite.linq4j.AbstractEnumerable(){
public org.apache.calcite.linq4j.Enumerator enumerator() {
return new org.apache.calcite.linq4j.Enumerator(){
public final org.apache.calcite.linq4j.Enumerator inputEnumerator =
_inputEnumerable00.enumerator();
public void reset() {
inputEnumerator.reset();
}
public boolean moveNext() {
while (inputEnumerator.moveNext()) {
[jira] [Updated] (CALCITE-4926) 'ORDER BY' misses alias/table of own 'WITH'
[
https://issues.apache.org/jira/browse/CALCITE-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4926:
--
Affects Version/s: 1.28.0
> 'ORDER BY' misses alias/table of own 'WITH'
> ---
>
> Key: CALCITE-4926
> URL: https://issues.apache.org/jira/browse/CALCITE-4926
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.28.0
>Reporter: Vladimir Steshin
>Priority: Minor
>
> "SELECT * FROM emp ORDER BY (WITH t AS (SELECT 1) SELECT * FROM t)"
> fails with:
> "Column 'T' not found in any table".
> Working similar one:
> "WITH t AS (SELECT 1) SELECT * FROM emp ORDER BY (SELECT * FROM t)"
> As I understand, SqlValidatorImpl#OrderExpressionExpander (extends
> SqlScopedShuttle) hurries to find the alias in the upper, parent query, whole
> "select * from ...". But this query and the related namespaces has no such
> alias. Probably, it's better to search order-by's namespace first.
>
> {code:java}
> newValidationError:5266, SqlValidatorImpl (org.apache.calcite.sql.validate)
> fullyQualify:273, DelegatingScope (org.apache.calcite.sql.validate)
> fullyQualify:95, OrderByScope (org.apache.calcite.sql.validate)
> visit:6548, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:6461, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> accept:324, SqlIdentifier (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> visit:80, SqlShuttle (org.apache.calcite.sql.util)
> visit:41, SqlShuttle (org.apache.calcite.sql.util)
> accept:266, SqlNodeList (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> go:6474, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> expandOrderExpr:4222, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateExpr:125, OrderByScope (org.apache.calcite.sql.validate)
> validateExpr:4467, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateOrderItem:4217, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateOrderList:4166, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateSelect:3658, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateImpl:64, SelectNamespace (org.apache.calcite.sql.validate)
> validate:89, AbstractNamespace (org.apache.calcite.sql.validate)
> validateNamespace:1100, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateQuery:1071, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validate:247, SqlSelect (org.apache.calcite.sql)
> validateScopedExpression:1046, SqlValidatorImpl
> (org.apache.calcite.sql.validate)
> validate:752, SqlValidatorImpl (org.apache.calcite.sql.validate)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4943) Type mismatch in Project / HepPlaner: INTEGER to JavaType(int)
[
https://issues.apache.org/jira/browse/CALCITE-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4943:
--
Affects Version/s: 1.29.0
> Type mismatch in Project / HepPlaner: INTEGER to JavaType(int)
> --
>
> Key: CALCITE-4943
> URL: https://issues.apache.org/jira/browse/CALCITE-4943
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.29.0
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: sub-query
>
> Found by JdbcTest.
> Test query:
> {code:sql}
> CalciteAssert.hr()
> .query("select (select (select t.\"empid\")) from \"hr\".\"emps\" t")
> .returnsCount(4);
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: type mismatch:
> ref:
> JavaType(int) NOT NULL
> input:
> INTEGER NOT NULL
> {code}
> Stacktrace:
> {code:java}
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
> at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:2211)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:129)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at org.apache.calcite.rel.core.Project.isValid(Project.java:219)
> at org.apache.calcite.rel.core.Project.(Project.java:98)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:69)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:126)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:114)
> at
> org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:178)
> at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:2020)
> at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1792)
> at
> org.apache.calcite.tools.RelBuilder.projectNamed(RelBuilder.java:2083)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.projectJoinOutputWithNullability(RelDecorrelator.java:1445)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.access$900(RelDecorrelator.java:147)
> at
> org.apache.calcite.sql2rel.RelDecorrelator$RemoveCorrelationForScalarProjectRule.onMatch(RelDecorrelator.java:2149)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:343)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:251)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:130)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.removeCorrelationViaRule(RelDecorrelator.java:378)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:221)
> at
> org.apache.calcite.tools.Programs$DecorrelateProgram.run(Programs.java:361)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:177)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:312)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4943) Type mismatch in Project / HepPlaner: INTEGER to JavaType(int)
[
https://issues.apache.org/jira/browse/CALCITE-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4943:
--
Priority: Major (was: Minor)
> Type mismatch in Project / HepPlaner: INTEGER to JavaType(int)
> --
>
> Key: CALCITE-4943
> URL: https://issues.apache.org/jira/browse/CALCITE-4943
> Project: Calcite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: sub-query
>
> Found by JdbcTest.
> Test query:
> {code:sql}
> CalciteAssert.hr()
> .query("select (select (select t.\"empid\")) from \"hr\".\"emps\" t")
> .returnsCount(4);
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: type mismatch:
> ref:
> JavaType(int) NOT NULL
> input:
> INTEGER NOT NULL
> {code}
> Stacktrace:
> {code:java}
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
> at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:2211)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:129)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at org.apache.calcite.rel.core.Project.isValid(Project.java:219)
> at org.apache.calcite.rel.core.Project.(Project.java:98)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:69)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:126)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:114)
> at
> org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:178)
> at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:2020)
> at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1792)
> at
> org.apache.calcite.tools.RelBuilder.projectNamed(RelBuilder.java:2083)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.projectJoinOutputWithNullability(RelDecorrelator.java:1445)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.access$900(RelDecorrelator.java:147)
> at
> org.apache.calcite.sql2rel.RelDecorrelator$RemoveCorrelationForScalarProjectRule.onMatch(RelDecorrelator.java:2149)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:343)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:251)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:130)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.removeCorrelationViaRule(RelDecorrelator.java:378)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:221)
> at
> org.apache.calcite.tools.Programs$DecorrelateProgram.run(Programs.java:361)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:177)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:312)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-685) Correlated scalar sub-query in SELECT clause throws
[
https://issues.apache.org/jira/browse/CALCITE-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17461060#comment-17461060
]
Vladimir Steshin commented on CALCITE-685:
--
[~julianhyde], I meant 1.29. Thanks. The bug is actual. Noted:
Fails:
{code:sql}
select e.department_id,
( select 1
from employee e2
where e.department_id = e2.department_id
)
from employee e
group by e.department_id
{code}
Works (fails with some kind of correct error 'more than one value in agg
SINGLE_VALUE'):
{code:sql}
select e.department_id,
( select 1
from employee e2
where e.department_id = e2.department_id
)
from employee e
with plan
PLAN=EnumerableCalc(expr#0..3=[{inputs}], department_id=[$t1], EXPR$1=[$t3])
EnumerableMergeJoin(condition=[=($1, $2)], joinType=[left])
EnumerableSort(sort0=[$1], dir0=[ASC])
EnumerableCalc(expr#0..16=[{inputs}], employee_id=[$t0],
department_id=[$t7])
EnumerableTableScan(table=[[foodmart2, employee]])
EnumerableSort(sort0=[$0], dir0=[ASC])
EnumerableAggregate(group=[{0}], agg#0=[SINGLE_VALUE($1)])
EnumerableCalc(expr#0..16=[{inputs}], expr#17=[1], department_id=[$t7],
EXPR$0=[$t17])
EnumerableTableScan(table=[[foodmart2, employee]])
{code}
> Correlated scalar sub-query in SELECT clause throws
> ---
>
> Key: CALCITE-685
> URL: https://issues.apache.org/jira/browse/CALCITE-685
> Project: Calcite
> Issue Type: Bug
>Reporter: Jinfeng Ni
>Priority: Major
> Labels: sub-query
>
> For the following query, where a correlated scalar subquery is put in select
> list, Calcite will hit NPE in RelDecorrelator.
> {code}
> select e.department_id, sum(e.employee_id),
>( select sum(e2.employee_id)
> from employee e2
> where e.department_id = e2.department_id
>)
> from employee e
> group by e.department_id;
> {code}
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.sql2rel.RelDecorrelator.createValueGenerator(RelDecorrelator.java:733)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateInputWithValueGenerator(RelDecorrelator.java:842)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateRel(RelDecorrelator.java:902)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:256)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:213)
> at
> org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:476)
> at
> org.apache.calcite.sql2rel.RelDecorrelator$DecorrelateRelVisitor.visit(RelDecorrelator.java:1420)
> at org.apache.calcite.rel.SingleRel.childrenAccept(SingleRel.java:72)
> .
> {code}
> Here is the unit test case I used to re-produce this problem in JdbcTest.java
> {code}
> @Test public void testCorreScalarSubQInSelect()
> throws ClassNotFoundException, SQLException {
> String query = "select e.department_id, sum(e.employee_id),\n"
> + " ( select sum(e2.employee_id)\n"
> + " from employee e2\n"
> + " where e.department_id = e2.department_id\n"
> + " )\n"
> + " from employee e\n"
> + " group by e.department_id\n";
> CalciteAssert.that()
> .with(CalciteAssert.Config.FOODMART_CLONE)
> .with(Lex.JAVA)
> .query(query)
> .returnsCount(0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CALCITE-685) Correlated scalar sub-query in SELECT clause throws
[
https://issues.apache.org/jira/browse/CALCITE-685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460739#comment-17460739
]
Vladimir Steshin commented on CALCITE-685:
--
On Calcite 1.19.0 from master branch I got:
{code:java}
Required columns {7} not subset of left columns {0, 1}
java.lang.AssertionError: Required columns {7} not subset of left columns {0, 1}
at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
at org.apache.calcite.util.Litmus$1.check(Litmus.java:44)
at org.apache.calcite.rel.core.Correlate.isValid(Correlate.java:127)
at org.apache.calcite.rel.core.Correlate.(Correlate.java:104)
at
org.apache.calcite.rel.logical.LogicalCorrelate.(LogicalCorrelate.java:66)
at
org.apache.calcite.rel.logical.LogicalCorrelate.create(LogicalCorrelate.java:94)
at
org.apache.calcite.rel.core.RelFactories$CorrelateFactoryImpl.createCorrelate(RelFactories.java:417)
at org.apache.calcite.tools.RelBuilder.join(RelBuilder.java:2789)
at
org.apache.calcite.rel.rules.SubQueryRemoveRule.rewriteScalarQuery(SubQueryRemoveRule.java:130)
at
org.apache.calcite.rel.rules.SubQueryRemoveRule.apply(SubQueryRemoveRule.java:93)
at
org.apache.calcite.rel.rules.SubQueryRemoveRule.matchProject(SubQueryRemoveRule.java:785)
at
org.apache.calcite.rel.rules.SubQueryRemoveRule.access$200(SubQueryRemoveRule.java:74)
at
org.apache.calcite.rel.rules.SubQueryRemoveRule$Config.lambda$static$0(SubQueryRemoveRule.java:863)
at
org.apache.calcite.rel.rules.SubQueryRemoveRule.onMatch(SubQueryRemoveRule.java:85)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:343)
at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
at
org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
at
org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:282)
at
org.apache.calcite.plan.hep.HepInstruction$RuleCollection.execute(HepInstruction.java:77)
at
org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
at
org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
at org.apache.calcite.tools.Programs.lambda$of$0(Programs.java:177)
at
org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:177)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:306)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
at
org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:249)
at
org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:623)
at
org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:675)
at
org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:156)
at
org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
at
org.apache.calcite.test.CalciteAssert.assertQuery(CalciteAssert.java:542)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.lambda$returns$1(CalciteAssert.java:1562)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.withConnection(CalciteAssert.java:1501)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.returns(CalciteAssert.java:1560)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.explainMatches(CalciteAssert.java:1754)
at
org.apache.calcite.test.CalciteAssert$AssertQuery.explainContains(CalciteAssert.java:1650)
at
org.apache.calcite.test.JdbcTest.testCorrelatedScalarSubQuery(JdbcTest.java:5114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:725)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutInvocation.proceed(TimeoutInvocation.java:46)
at
[jira] [Updated] (CALCITE-4926) 'ORDER BY' misses alias/table of own 'WITH'
[
https://issues.apache.org/jira/browse/CALCITE-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4926:
--
Labels: with (was: orderby)
> 'ORDER BY' misses alias/table of own 'WITH'
> ---
>
> Key: CALCITE-4926
> URL: https://issues.apache.org/jira/browse/CALCITE-4926
> Project: Calcite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: with
>
> "SELECT * FROM emp ORDER BY (WITH t AS (SELECT 1) SELECT * FROM t)"
> fails with:
> "Column 'T' not found in any table".
> Working similar one:
> "WITH t AS (SELECT 1) SELECT * FROM emp ORDER BY (SELECT * FROM t)"
> As I understand, SqlValidatorImpl#OrderExpressionExpander (extends
> SqlScopedShuttle) hurries to find the alias in the upper, parent query, whole
> "select * from ...". But this query and the related namespaces has no such
> alias. Probably, it's better to search order-by's namespace first.
>
> {code:java}
> newValidationError:5266, SqlValidatorImpl (org.apache.calcite.sql.validate)
> fullyQualify:273, DelegatingScope (org.apache.calcite.sql.validate)
> fullyQualify:95, OrderByScope (org.apache.calcite.sql.validate)
> visit:6548, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:6461, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> accept:324, SqlIdentifier (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> visit:80, SqlShuttle (org.apache.calcite.sql.util)
> visit:41, SqlShuttle (org.apache.calcite.sql.util)
> accept:266, SqlNodeList (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> go:6474, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> expandOrderExpr:4222, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateExpr:125, OrderByScope (org.apache.calcite.sql.validate)
> validateExpr:4467, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateOrderItem:4217, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateOrderList:4166, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateSelect:3658, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateImpl:64, SelectNamespace (org.apache.calcite.sql.validate)
> validate:89, AbstractNamespace (org.apache.calcite.sql.validate)
> validateNamespace:1100, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateQuery:1071, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validate:247, SqlSelect (org.apache.calcite.sql)
> validateScopedExpression:1046, SqlValidatorImpl
> (org.apache.calcite.sql.validate)
> validate:752, SqlValidatorImpl (org.apache.calcite.sql.validate)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4926) 'ORDER BY' misses alias/table of own 'WITH'
[
https://issues.apache.org/jira/browse/CALCITE-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4926:
--
Labels: (was: with)
> 'ORDER BY' misses alias/table of own 'WITH'
> ---
>
> Key: CALCITE-4926
> URL: https://issues.apache.org/jira/browse/CALCITE-4926
> Project: Calcite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
>
> "SELECT * FROM emp ORDER BY (WITH t AS (SELECT 1) SELECT * FROM t)"
> fails with:
> "Column 'T' not found in any table".
> Working similar one:
> "WITH t AS (SELECT 1) SELECT * FROM emp ORDER BY (SELECT * FROM t)"
> As I understand, SqlValidatorImpl#OrderExpressionExpander (extends
> SqlScopedShuttle) hurries to find the alias in the upper, parent query, whole
> "select * from ...". But this query and the related namespaces has no such
> alias. Probably, it's better to search order-by's namespace first.
>
> {code:java}
> newValidationError:5266, SqlValidatorImpl (org.apache.calcite.sql.validate)
> fullyQualify:273, DelegatingScope (org.apache.calcite.sql.validate)
> fullyQualify:95, OrderByScope (org.apache.calcite.sql.validate)
> visit:6548, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:6461, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> accept:324, SqlIdentifier (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> visit:80, SqlShuttle (org.apache.calcite.sql.util)
> visit:41, SqlShuttle (org.apache.calcite.sql.util)
> accept:266, SqlNodeList (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> go:6474, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> expandOrderExpr:4222, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateExpr:125, OrderByScope (org.apache.calcite.sql.validate)
> validateExpr:4467, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateOrderItem:4217, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateOrderList:4166, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateSelect:3658, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateImpl:64, SelectNamespace (org.apache.calcite.sql.validate)
> validate:89, AbstractNamespace (org.apache.calcite.sql.validate)
> validateNamespace:1100, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateQuery:1071, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validate:247, SqlSelect (org.apache.calcite.sql)
> validateScopedExpression:1046, SqlValidatorImpl
> (org.apache.calcite.sql.validate)
> validate:752, SqlValidatorImpl (org.apache.calcite.sql.validate)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4926) 'ORDER BY' misses alias/table of own 'WITH'
[
https://issues.apache.org/jira/browse/CALCITE-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4926:
--
Labels: orderby (was: )
> 'ORDER BY' misses alias/table of own 'WITH'
> ---
>
> Key: CALCITE-4926
> URL: https://issues.apache.org/jira/browse/CALCITE-4926
> Project: Calcite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: orderby
>
> "SELECT * FROM emp ORDER BY (WITH t AS (SELECT 1) SELECT * FROM t)"
> fails with:
> "Column 'T' not found in any table".
> Working similar one:
> "WITH t AS (SELECT 1) SELECT * FROM emp ORDER BY (SELECT * FROM t)"
> As I understand, SqlValidatorImpl#OrderExpressionExpander (extends
> SqlScopedShuttle) hurries to find the alias in the upper, parent query, whole
> "select * from ...". But this query and the related namespaces has no such
> alias. Probably, it's better to search order-by's namespace first.
>
> {code:java}
> newValidationError:5266, SqlValidatorImpl (org.apache.calcite.sql.validate)
> fullyQualify:273, DelegatingScope (org.apache.calcite.sql.validate)
> fullyQualify:95, OrderByScope (org.apache.calcite.sql.validate)
> visit:6548, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:6461, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> accept:324, SqlIdentifier (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> visit:80, SqlShuttle (org.apache.calcite.sql.util)
> visit:41, SqlShuttle (org.apache.calcite.sql.util)
> accept:266, SqlNodeList (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
> acceptCall:954, SqlOperator (org.apache.calcite.sql)
> visit:68, SqlShuttle (org.apache.calcite.sql.util)
> visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
> visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
> accept:161, SqlCall (org.apache.calcite.sql)
> go:6474, SqlValidatorImpl$OrderExpressionExpander
> (org.apache.calcite.sql.validate)
> expandOrderExpr:4222, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateExpr:125, OrderByScope (org.apache.calcite.sql.validate)
> validateExpr:4467, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateOrderItem:4217, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateOrderList:4166, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateSelect:3658, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateImpl:64, SelectNamespace (org.apache.calcite.sql.validate)
> validate:89, AbstractNamespace (org.apache.calcite.sql.validate)
> validateNamespace:1100, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validateQuery:1071, SqlValidatorImpl (org.apache.calcite.sql.validate)
> validate:247, SqlSelect (org.apache.calcite.sql)
> validateScopedExpression:1046, SqlValidatorImpl
> (org.apache.calcite.sql.validate)
> validate:752, SqlValidatorImpl (org.apache.calcite.sql.validate)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4943) Type mismatch in Project / HepPlaner: INTEGER to JavaType(int)
[
https://issues.apache.org/jira/browse/CALCITE-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4943:
--
Labels: sub-query (was: )
> Type mismatch in Project / HepPlaner: INTEGER to JavaType(int)
> --
>
> Key: CALCITE-4943
> URL: https://issues.apache.org/jira/browse/CALCITE-4943
> Project: Calcite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
> Labels: sub-query
>
> Found by JdbcTest.
> Test query:
> {code:sql}
> CalciteAssert.hr()
> .query("select (select (select t.\"empid\")) from \"hr\".\"emps\" t")
> .returnsCount(4);
> {code}
> Error:
> {code:java}
> java.lang.AssertionError: type mismatch:
> ref:
> JavaType(int) NOT NULL
> input:
> INTEGER NOT NULL
> {code}
> Stacktrace:
> {code:java}
> at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
> at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:2211)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:129)
> at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61)
> at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144)
> at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> at org.apache.calcite.rel.core.Project.isValid(Project.java:219)
> at org.apache.calcite.rel.core.Project.(Project.java:98)
> at
> org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:69)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:126)
> at
> org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:114)
> at
> org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:178)
> at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:2020)
> at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1792)
> at
> org.apache.calcite.tools.RelBuilder.projectNamed(RelBuilder.java:2083)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.projectJoinOutputWithNullability(RelDecorrelator.java:1445)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.access$900(RelDecorrelator.java:147)
> at
> org.apache.calcite.sql2rel.RelDecorrelator$RemoveCorrelationForScalarProjectRule.onMatch(RelDecorrelator.java:2149)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:343)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:251)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:130)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.removeCorrelationViaRule(RelDecorrelator.java:378)
> at
> org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:221)
> at
> org.apache.calcite.tools.Programs$DecorrelateProgram.run(Programs.java:361)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:177)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:312)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4943) Type mismatch in Project / HepPlaner: INTEGER to JavaType(int)
[
https://issues.apache.org/jira/browse/CALCITE-4943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4943:
--
Description:
Found by JdbcTest.
Test query:
{code:sql}
CalciteAssert.hr()
.query("select (select (select t.\"empid\")) from \"hr\".\"emps\" t")
.returnsCount(4);
{code}
Error:
{code:java}
java.lang.AssertionError: type mismatch:
ref:
JavaType(int) NOT NULL
input:
INTEGER NOT NULL
{code}
Stacktrace:
{code:java}
at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:2211)
at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:129)
at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61)
at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144)
at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
at org.apache.calcite.rel.core.Project.isValid(Project.java:219)
at org.apache.calcite.rel.core.Project.(Project.java:98)
at
org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:69)
at
org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:126)
at
org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:114)
at
org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:178)
at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:2020)
at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1792)
at
org.apache.calcite.tools.RelBuilder.projectNamed(RelBuilder.java:2083)
at
org.apache.calcite.sql2rel.RelDecorrelator.projectJoinOutputWithNullability(RelDecorrelator.java:1445)
at
org.apache.calcite.sql2rel.RelDecorrelator.access$900(RelDecorrelator.java:147)
at
org.apache.calcite.sql2rel.RelDecorrelator$RemoveCorrelationForScalarProjectRule.onMatch(RelDecorrelator.java:2149)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:343)
at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
at
org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
at
org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:251)
at
org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:130)
at
org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
at
org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
at
org.apache.calcite.sql2rel.RelDecorrelator.removeCorrelationViaRule(RelDecorrelator.java:378)
at
org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:221)
at
org.apache.calcite.tools.Programs$DecorrelateProgram.run(Programs.java:361)
at
org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:177)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:312)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
{code}
was:
Found by JdbcTest.
Test query:
{code:sql}
select (select (select t."empid")) from "hr"."emps" t
{code}
Error:
{code:java}
java.lang.AssertionError: type mismatch:
ref:
JavaType(int) NOT NULL
input:
INTEGER NOT NULL
{code}
Stacktrace:
{code:java}
at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:2211)
at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:129)
at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61)
at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144)
at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
at org.apache.calcite.rel.core.Project.isValid(Project.java:219)
at org.apache.calcite.rel.core.Project.(Project.java:98)
at
org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:69)
at
org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:126)
at
org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:114)
[jira] [Created] (CALCITE-4943) Type conversin in Project / HepPlaner: INTEGER to JavaType(int)
Vladimir Steshin created CALCITE-4943:
-
Summary: Type conversin in Project / HepPlaner: INTEGER to
JavaType(int)
Key: CALCITE-4943
URL: https://issues.apache.org/jira/browse/CALCITE-4943
Project: Calcite
Issue Type: Bug
Reporter: Vladimir Steshin
Found by JdbcTest.
Test query:
{code:sql}
select (select (select t."empid")) from "hr"."emps" t
{code}
Error:
{code:java}
java.lang.AssertionError: type mismatch:
ref:
JavaType(int) NOT NULL
input:
INTEGER NOT NULL
{code}
Stacktrace:
{code:java}
at org.apache.calcite.util.Litmus$1.fail(Litmus.java:32)
at org.apache.calcite.plan.RelOptUtil.eq(RelOptUtil.java:2211)
at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:129)
at org.apache.calcite.rex.RexChecker.visitInputRef(RexChecker.java:61)
at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:114)
at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:144)
at org.apache.calcite.rex.RexChecker.visitCall(RexChecker.java:61)
at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
at org.apache.calcite.rel.core.Project.isValid(Project.java:219)
at org.apache.calcite.rel.core.Project.(Project.java:98)
at
org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:69)
at
org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:126)
at
org.apache.calcite.rel.logical.LogicalProject.create(LogicalProject.java:114)
at
org.apache.calcite.rel.core.RelFactories$ProjectFactoryImpl.createProject(RelFactories.java:178)
at org.apache.calcite.tools.RelBuilder.project_(RelBuilder.java:2020)
at org.apache.calcite.tools.RelBuilder.project(RelBuilder.java:1792)
at
org.apache.calcite.tools.RelBuilder.projectNamed(RelBuilder.java:2083)
at
org.apache.calcite.sql2rel.RelDecorrelator.projectJoinOutputWithNullability(RelDecorrelator.java:1445)
at
org.apache.calcite.sql2rel.RelDecorrelator.access$900(RelDecorrelator.java:147)
at
org.apache.calcite.sql2rel.RelDecorrelator$RemoveCorrelationForScalarProjectRule.onMatch(RelDecorrelator.java:2149)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:343)
at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
at
org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
at
org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:251)
at
org.apache.calcite.plan.hep.HepInstruction$RuleInstance.execute(HepInstruction.java:130)
at
org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
at
org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
at
org.apache.calcite.sql2rel.RelDecorrelator.removeCorrelationViaRule(RelDecorrelator.java:378)
at
org.apache.calcite.sql2rel.RelDecorrelator.decorrelateQuery(RelDecorrelator.java:221)
at
org.apache.calcite.tools.Programs$DecorrelateProgram.run(Programs.java:361)
at
org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:336)
at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:177)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:312)
at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:220)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:647)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:513)
at
org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:483)
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (CALCITE-4926) 'ORDER BY' misses alias/table of own 'WITH'
[
https://issues.apache.org/jira/browse/CALCITE-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4926:
--
Description:
"SELECT * FROM emp ORDER BY (WITH t AS (SELECT 1) SELECT * FROM t)"
fails with:
"Column 'T' not found in any table".
Working similar one:
"WITH t AS (SELECT 1) SELECT * FROM emp ORDER BY (SELECT * FROM t)"
As I understand, SqlValidatorImpl#OrderExpressionExpander (extends
SqlScopedShuttle) hurries to find the alias in the upper, parent query, whole
"select * from ...". But this query and the related namespaces has no such
alias. Probably, it's better to search order-by's namespace first.
{code:java}
newValidationError:5266, SqlValidatorImpl (org.apache.calcite.sql.validate)
fullyQualify:273, DelegatingScope (org.apache.calcite.sql.validate)
fullyQualify:95, OrderByScope (org.apache.calcite.sql.validate)
visit:6548, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
visit:6461, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
accept:324, SqlIdentifier (org.apache.calcite.sql)
visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
acceptCall:954, SqlOperator (org.apache.calcite.sql)
visit:68, SqlShuttle (org.apache.calcite.sql.util)
visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
accept:161, SqlCall (org.apache.calcite.sql)
visit:80, SqlShuttle (org.apache.calcite.sql.util)
visit:41, SqlShuttle (org.apache.calcite.sql.util)
accept:266, SqlNodeList (org.apache.calcite.sql)
visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
acceptCall:954, SqlOperator (org.apache.calcite.sql)
visit:68, SqlShuttle (org.apache.calcite.sql.util)
visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
accept:161, SqlCall (org.apache.calcite.sql)
visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
acceptCall:954, SqlOperator (org.apache.calcite.sql)
visit:68, SqlShuttle (org.apache.calcite.sql.util)
visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
accept:161, SqlCall (org.apache.calcite.sql)
go:6474, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
expandOrderExpr:4222, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateExpr:125, OrderByScope (org.apache.calcite.sql.validate)
validateExpr:4467, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateOrderItem:4217, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateOrderList:4166, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateSelect:3658, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateImpl:64, SelectNamespace (org.apache.calcite.sql.validate)
validate:89, AbstractNamespace (org.apache.calcite.sql.validate)
validateNamespace:1100, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateQuery:1071, SqlValidatorImpl (org.apache.calcite.sql.validate)
validate:247, SqlSelect (org.apache.calcite.sql)
validateScopedExpression:1046, SqlValidatorImpl
(org.apache.calcite.sql.validate)
validate:752, SqlValidatorImpl (org.apache.calcite.sql.validate)
{code}
was:
"SELECT * FROM emp ORDER BY (WITH t AS (SELECT 1) SELECT * FROM t)"
fails with:
"Column 'T' not found in any table".
Working similar one:
"WITH t AS (SELECT 1) SELECT * FROM emp ORDER BY (SELECT * FROM t)"
As I understand, SqlValidatorImpl#OrderExpressionExpander (extends
SqlScopedShuttle) hurries to find the alias in the upper, parent query, whole
"select * from ...". But this query and the related namespaces has no such
alias. Probably, it's better to search order-by's namespace first.
{code:java}
:57, SqlValidatorException (org.apache.calcite.sql.validate)
newInstance0:-1, NativeConstructorAccessorImpl (sun.reflect)
newInstance:62, NativeConstructorAccessorImpl (sun.reflect)
newInstance:45, DelegatingConstructorAccessorImpl (sun.reflect)
newInstance:423, Constructor (java.lang.reflect)
ex:505, Resources$ExInstWithCause (org.apache.calcite.runtime)
ex:599, Resources$ExInst
[jira] [Updated] (CALCITE-4926) 'ORDER BY' misses alias/table of own 'WITH'
[
https://issues.apache.org/jira/browse/CALCITE-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated CALCITE-4926:
--
Description:
"SELECT * FROM emp ORDER BY (WITH t AS (SELECT 1) SELECT * FROM t)"
fails with:
"Column 'T' not found in any table".
Working similar one:
"WITH t AS (SELECT 1) SELECT * FROM emp ORDER BY (SELECT * FROM t)"
As I understand, SqlValidatorImpl#OrderExpressionExpander (extends
SqlScopedShuttle) hurries to find the alias in the upper, parent query, whole
"select * from ...". But this query and the related namespaces has no such
alias. Probably, it's better to search order-by's namespace first.
{code:java}
:57, SqlValidatorException (org.apache.calcite.sql.validate)
newInstance0:-1, NativeConstructorAccessorImpl (sun.reflect)
newInstance:62, NativeConstructorAccessorImpl (sun.reflect)
newInstance:45, DelegatingConstructorAccessorImpl (sun.reflect)
newInstance:423, Constructor (java.lang.reflect)
ex:505, Resources$ExInstWithCause (org.apache.calcite.runtime)
ex:599, Resources$ExInst (org.apache.calcite.runtime)
newContextException:932, SqlUtil (org.apache.calcite.sql)
newContextException:917, SqlUtil (org.apache.calcite.sql)
newValidationError:5266, SqlValidatorImpl (org.apache.calcite.sql.validate)
fullyQualify:273, DelegatingScope (org.apache.calcite.sql.validate)
fullyQualify:95, OrderByScope (org.apache.calcite.sql.validate)
visit:6548, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
visit:6461, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
accept:324, SqlIdentifier (org.apache.calcite.sql)
visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
acceptCall:954, SqlOperator (org.apache.calcite.sql)
visit:68, SqlShuttle (org.apache.calcite.sql.util)
visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
accept:161, SqlCall (org.apache.calcite.sql)
visit:80, SqlShuttle (org.apache.calcite.sql.util)
visit:41, SqlShuttle (org.apache.calcite.sql.util)
accept:266, SqlNodeList (org.apache.calcite.sql)
visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
acceptCall:954, SqlOperator (org.apache.calcite.sql)
visit:68, SqlShuttle (org.apache.calcite.sql.util)
visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
accept:161, SqlCall (org.apache.calcite.sql)
visitChild:134, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
visitChild:101, SqlShuttle$CallCopyingArgHandler (org.apache.calcite.sql.util)
acceptCall:954, SqlOperator (org.apache.calcite.sql)
visit:68, SqlShuttle (org.apache.calcite.sql.util)
visitScoped:64, SqlScopedShuttle (org.apache.calcite.sql.validate)
visitScoped:6557, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
visit:54, SqlScopedShuttle (org.apache.calcite.sql.validate)
visit:37, SqlScopedShuttle (org.apache.calcite.sql.validate)
accept:161, SqlCall (org.apache.calcite.sql)
go:6474, SqlValidatorImpl$OrderExpressionExpander
(org.apache.calcite.sql.validate)
expandOrderExpr:4222, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateExpr:125, OrderByScope (org.apache.calcite.sql.validate)
validateExpr:4467, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateOrderItem:4217, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateOrderList:4166, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateSelect:3658, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateImpl:64, SelectNamespace (org.apache.calcite.sql.validate)
validate:89, AbstractNamespace (org.apache.calcite.sql.validate)
validateNamespace:1100, SqlValidatorImpl (org.apache.calcite.sql.validate)
validateQuery:1071, SqlValidatorImpl (org.apache.calcite.sql.validate)
validate:247, SqlSelect (org.apache.calcite.sql)
validateScopedExpression:1046, SqlValidatorImpl
(org.apache.calcite.sql.validate)
validate:752, SqlValidatorImpl (org.apache.calcite.sql.validate)
assertExceptionIsThrown:129, AbstractSqlTester (org.apache.calcite.sql.test)
ok:315, SqlValidatorTestCase$Sql (org.apache.calcite.test)
testOrder1:6551, SqlValidatorTest (org.apache.calcite.test)
invoke0:-1, NativeMethodAccessorImpl (sun.reflect)
invoke:62, NativeMethodAccessorImpl (sun.reflect)
invoke:43, DelegatingMethodAccessorImpl (sun.reflect)
invoke:498, Method
[jira] [Created] (CALCITE-4926) 'ORDER BY' misses alias/table of own 'WITH'
Vladimir Steshin created CALCITE-4926: - Summary: 'ORDER BY' misses alias/table of own 'WITH' Key: CALCITE-4926 URL: https://issues.apache.org/jira/browse/CALCITE-4926 Project: Calcite Issue Type: Bug Reporter: Vladimir Steshin "SELECT * FROM emp ORDER BY (WITH t AS (SELECT 1) SELECT * FROM t)" fails with: "Column 'T' not found in any table". Working similar one: "WITH t AS (SELECT 1) SELECT * FROM emp ORDER BY (SELECT * FROM t)" As I understand, SqlValidatorImpl#OrderExpressionExpander (extends SqlScopedShuttle) hurries to find the alias in the upper, parent query, whole "select * from ...". But this query and the related namespaces has no such alias. Probably, it's better to search order-by's namespace first. -- This message was sent by Atlassian Jira (v8.20.1#820001)
