[jira] [Assigned] (CALCITE-3383) Allow plural time units in interval literals
[
https://issues.apache.org/jira/browse/CALCITE-3383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde reassigned CALCITE-3383:
Assignee: Julian Hyde
> Allow plural time units in interval literals
>
>
> Key: CALCITE-3383
> URL: https://issues.apache.org/jira/browse/CALCITE-3383
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> Allow plural time units in interval literals. For example, currently, Calcite
> allows {{INTERVAL '2' DAY}} but gives an error for {{INTERVAL '2' DAYS}}.
> (Note: DAY vs DAYS.)
> Standard SQL only allows the first; PostgreSQL allows both.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3379) Support expand STRING column expression in table during sql-to-rel conversion
[ https://issues.apache.org/jira/browse/CALCITE-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948187#comment-16948187 ] Danny Chen commented on CALCITE-3379: - Yes, column expression need to be validated, this is resolved in CALCITE-3392. > Support expand STRING column expression in table during sql-to-rel conversion > - > > Key: CALCITE-3379 > URL: https://issues.apache.org/jira/browse/CALCITE-3379 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: Danny Chen >Assignee: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Now there are 2 ways to convert a RelOptTable to LogicalTableScan: > 1. One way is to open the Config#isConvertTableAccess[1] flag and the > SqlToRelConverter would invoke the #toRel method which transforms the table > to a node returned by the user(Usually a table scan). > 2. Another way is to use the LogicalTableScan rule, this rule would invoke > RelOptTable#toRel and wrap the returned node with a LogicalTableScan. > > The difference between 1 and 2 is that, 2 happens in the planning rule but 1 > happens in sql-to-rel conversion, 1 also supports to expand the table columns > based on the defined default values expressions, see > InitializerExpressionFactory#newColumnDefaultValue. > > The problem with the InitializerExpressionFactory#newColumnDefaultValue is > that it uses InitializerContext#convertExpression to convert a SqlNode, but > if the SqlNode is not validated, we always got a RexCall with > SqlUnresolvedFunction. We should give the user chance to validate their > SqlNode or even we can support pure string expressions which can be used to > persist. > > Another problem with #toRel is that after the expressions applied as a > projection, user has no chance to apply any other relational nodes if they > want, we can actually support this, the same way as we support the column > expressions. > > [1]https://github.com/apache/calcite/blob/2dc97e6723e1b5bf762540f87b5cd1a848a1/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L5605 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3392) Column expression in DDL should be validated before converting to RexNode
[ https://issues.apache.org/jira/browse/CALCITE-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen resolved CALCITE-3392. - Resolution: Fixed Fixed in [aafa583|https://github.com/apache/calcite/commit/aafa583234ef160f521e4facb5648d3838f37067] ! > Column expression in DDL should be validated before converting to RexNode > - > > Key: CALCITE-3392 > URL: https://issues.apache.org/jira/browse/CALCITE-3392 > Project: Calcite > Issue Type: Sub-task > Components: core >Affects Versions: 1.21.0 >Reporter: Danny Chen >Assignee: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 20m > Remaining Estimate: 0h > > As described in CALCITE-3379, we should validate the column expression so > that the expression can be converted correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3300) Add a star identifier as operand to "SqlCountAggFunction" if no operands given while in the method "createCall"
[
https://issues.apache.org/jira/browse/CALCITE-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948167#comment-16948167
]
Wang Weidong edited comment on CALCITE-3300 at 10/10/19 3:31 AM:
-
[~julianhyde] Will you reply my discussion ？
was (Author: wangweidong):
[~julianhyde] Will reply my discussion ？
> Add a star identifier as operand to "SqlCountAggFunction" if no operands
> given while in the method "createCall"
> ---
>
> Key: CALCITE-3300
> URL: https://issues.apache.org/jira/browse/CALCITE-3300
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Weidong
>Assignee: Wang Weidong
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h4. Procedure to reproduce the problem:
> - create table {{~^t^~}}
> - parse query select count(*) from t to SqlNode
> - convert SqlNode to RelNode
> - convert RelNode to SqlNode
> - validate the result SqlNode
> test code is like this
> {code:java}
> // code placeholder
> @Test
> public void testSelectCountAll() throws Exception {
> try (Statement s = parserContext.getStatement()) {
> s.execute("create table if not exists t (i int not null)");
> String sql = "select count(*) from t";
> SqlNode sqlNode = parserContext.parseStmt(sql);
> parserContext.getSqlValidator().validate(sqlNode);
> RelNode relNode =
> parserContext.getSqlToRelConverter().convertQuery(sqlNode, true, true).rel;
> SqlNode sqlNodeNew = toSqlNode(relNode);
> parserContext.getSqlValidator().validate(sqlNodeNew);
> }
> }
> {code}
> Finally we will get an exception as follow:
> {code:java}
> // code placeholder
> org.apache.calcite.runtime.CalciteContextException: At line 0, column 0:
> Invalid number of arguments to function 'COUNT'. Was expecting 1
> argumentsorg.apache.calcite.runtime.CalciteContextException: At line 0,
> column 0: Invalid number of arguments to function 'COUNT'. Was expecting 1
> arguments at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:783) at
> org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4753)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.handleUnresolvedFunction(SqlValidatorImpl.java:1699)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:270) at
> org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215) at
> org.apache.calcite.sql.fun.SqlCountAggFunction.deriveType(SqlCountAggFunction.java:83)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5477)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5464)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1629)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1614)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4017)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3280)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:967)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:943)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:225) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:918)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:628)
> at
> org.apache.calcite.test.OptimizeTest.testSelectCountAll(OptimizeTest.java:220)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>
[jira] [Commented] (CALCITE-3300) Add a star identifier as operand to "SqlCountAggFunction" if no operands given while in the method "createCall"
[
https://issues.apache.org/jira/browse/CALCITE-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948167#comment-16948167
]
Wang Weidong commented on CALCITE-3300:
---
[~julianhyde] Will reply my discussion ？
> Add a star identifier as operand to "SqlCountAggFunction" if no operands
> given while in the method "createCall"
> ---
>
> Key: CALCITE-3300
> URL: https://issues.apache.org/jira/browse/CALCITE-3300
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Wang Weidong
>Assignee: Wang Weidong
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h4. Procedure to reproduce the problem:
> - create table {{~^t^~}}
> - parse query select count(*) from t to SqlNode
> - convert SqlNode to RelNode
> - convert RelNode to SqlNode
> - validate the result SqlNode
> test code is like this
> {code:java}
> // code placeholder
> @Test
> public void testSelectCountAll() throws Exception {
> try (Statement s = parserContext.getStatement()) {
> s.execute("create table if not exists t (i int not null)");
> String sql = "select count(*) from t";
> SqlNode sqlNode = parserContext.parseStmt(sql);
> parserContext.getSqlValidator().validate(sqlNode);
> RelNode relNode =
> parserContext.getSqlToRelConverter().convertQuery(sqlNode, true, true).rel;
> SqlNode sqlNodeNew = toSqlNode(relNode);
> parserContext.getSqlValidator().validate(sqlNodeNew);
> }
> }
> {code}
> Finally we will get an exception as follow:
> {code:java}
> // code placeholder
> org.apache.calcite.runtime.CalciteContextException: At line 0, column 0:
> Invalid number of arguments to function 'COUNT'. Was expecting 1
> argumentsorg.apache.calcite.runtime.CalciteContextException: At line 0,
> column 0: Invalid number of arguments to function 'COUNT'. Was expecting 1
> arguments at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method) at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:783) at
> org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:768) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4753)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.handleUnresolvedFunction(SqlValidatorImpl.java:1699)
> at org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:270) at
> org.apache.calcite.sql.SqlFunction.deriveType(SqlFunction.java:215) at
> org.apache.calcite.sql.fun.SqlCountAggFunction.deriveType(SqlCountAggFunction.java:83)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5477)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$DeriveTypeVisitor.visit(SqlValidatorImpl.java:5464)
> at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveTypeImpl(SqlValidatorImpl.java:1629)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.deriveType(SqlValidatorImpl.java:1614)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:457)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4017)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3280)
> at
> org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60)
> at
> org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:967)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:943)
> at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:225) at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:918)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:628)
> at
> org.apache.calcite.test.OptimizeTest.testSelectCountAll(OptimizeTest.java:220)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Commented] (CALCITE-3395) add BuiltinMethod for Substring(String, int)
[ https://issues.apache.org/jira/browse/CALCITE-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948127#comment-16948127 ] Danny Chen commented on CALCITE-3395: - Calcite support 2 style of subString function: # One is SUBSTRING(str FROM pos FOR len) defined in SqlStdOperatorTable[1] # Another is SUBSTR(string, position [, substringLength ]) defined in SqlLibraryOperators as a ORACLE dialect operator[2] [1] https://github.com/apache/calcite/blob/e43595482617b1bb991407800c068a0c727e5c17/core/src/main/java/org/apache/calcite/sql/fun/SqlStdOperatorTable.java#L1443 [2] https://github.com/apache/calcite/blob/e43595482617b1bb991407800c068a0c727e5c17/core/src/main/java/org/apache/calcite/sql/fun/SqlLibraryOperators.java#L118 > add BuiltinMethod for Substring(String, int) > > > Key: CALCITE-3395 > URL: https://issues.apache.org/jira/browse/CALCITE-3395 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Youjun Yuan >Priority: Minor > Original Estimate: 4h > Remaining Estimate: 4h > > substring function has two versoins: > 1, Substring(String, int, int) > 2, Substring(String, int) > currently in BuiltinMethod.java, only the first one is defined. Need to > define the second one as well, so that we can use both of them. > Apache Flink(FunctionGenerator.scala), reference the BuiltinMethod, since > Calcite only defines 1, not 2, Flink always resolve SUBSTRING to > Substring(String, int, int) even if there is only 2 parameters. This problem > happens to be covered by method overloading of java, but it's still a > potential problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3394) Can not register implementation of a UDF with RexImpTable and use the same with RelBuilder
[
https://issues.apache.org/jira/browse/CALCITE-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948122#comment-16948122
]
Danny Chen commented on CALCITE-3394:
-
[~vaishnavee] This is because
SqlStdOperatorTable.instance()
did some initialization work for the registered functions. So an invoke of
#register after it would not work as expected.
The correct way is to use ListSqlOperatorTable and chained it with the
StdSqlOperatorTable with ChainedSqlOperatorTable, the presudo code may like
this:
{code:java}
ListSqlOperatorTable listOpTable = new ListSqlOperatorTable();
listOpTable.add(my_udf);
ChainedSqlOperatorTable chainedOpTable =
ChainedSqlOperatorTable.of(listOpTable, SqlStdOperatorTable.instance());
// then use this chainedOpTable
// If you want to use a special dialect operators, you can code like this
SqlOperatorTable optable = SqlLibraryOperatorTableFactory.INSTANCE
.getOperatorTable(SqlLibrary.STANDARD, SqlLibrary.POSTGRESQL);{code}
> Can not register implementation of a UDF with RexImpTable and use the same
> with RelBuilder
> --
>
> Key: CALCITE-3394
> URL: https://issues.apache.org/jira/browse/CALCITE-3394
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Vaishnavee Kulkarni
>Priority: Major
>
> I am trying to register a simple UDF that returns the length of input string.
> I can do this with prepareStatement approach -
> {code:java}
> public static class MyUdf1 {
>public Integer eval(String a) {
> return a.length();
>}
> }
> public void testUDF() {
> final String strLenSql = "select STRLEN('SampleString') from emp";
> ScalarFunction strLenFunction = ScalarFunctionImpl.create(MyUdf1.class,
> "eval");
> calciteConnection.getRootSchema().add("STRLEN", strLenFunction);
> ResultSet resultSet =
> calciteConnection.prepareStatement(strLenSql).executeQuery();
> resultSet.next();
> System.out.println(resultSet.getString(1));
> }
> {code}
>
> When I try the similar steps with _RelBuilder_, I can successfully register
> the _SqlOperator_; but am unable to refer to the implementation of this
> operator. The builder refers to _RexImpTable_'s maps for the function table
> implementation and there is no public/protected api exposed for these maps.
> {code:java}
> SqlFunction length = new SqlFunction("STRLEN",
> SqlKind.OTHER_FUNCTION,
> ReturnTypes.INTEGER,
> null,
> OperandTypes.STRING,
> SqlFunctionCategory.USER_DEFINED_FUNCTION);
> SqlStdOperatorTable sqlStdOperatorTable = SqlStdOperatorTable.instance();
> sqlStdOperatorTable.register(length);
> FrameworkConfig frameworkConfig = Frameworks.newConfigBuilder()
> .parserConfig(SqlParser.Config.DEFAULT)
> .defaultSchema(connection.getRootSchema().getSubSchema("SYSTEM"))
> .programs(Programs.sequence(Programs.ofRules(Programs.RULE_SET),
> Programs.CALC_PROGRAM))
> .operatorTable(sqlStdOperatorTable)
> .build();
> final RelBuilder builder = RelBuilder.create(frameworkConfig);
> RelNode udfRelNode = builder
> .scan("EMP")
> .project(builder.call(length,builder.literal("SampleString")))
> .build();
> ResultSet resultSet = RelRunners.run(udfRelNode).executeQuery();
> {code}
>
> This code throws exception -
> {code:java}
> Caused by: java.lang.RuntimeException: cannot translate call
> STRLEN($t3)Caused by: java.lang.RuntimeException: cannot translate call
> STRLEN($t3) at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCall(RexToLixTranslator.java:756)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:730)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:199)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:684)
> {code}
> There are no junits that show this working with _RelBuilder_. Is it possible
> currently to register and use the udfs with RelBuilder?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3390) ITEM expression does not get pushed to the right input of left-outer-join
[
https://issues.apache.org/jira/browse/CALCITE-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3390:
Labels: pull-request-available (was: )
> ITEM expression does not get pushed to the right input of left-outer-join
> -
>
> Key: CALCITE-3390
> URL: https://issues.apache.org/jira/browse/CALCITE-3390
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Aman Sinha
>Assignee: Aman Sinha
>Priority: Major
> Labels: pull-request-available
>
> In the following query, the ITEM expression above the Left Outer Join does
> not get pushed to the right input (null-preserving input) of the join whereas
> it should since ITEM does not change the nullability.
> {noformat}
> explain plan without implementation for select tt7.columns[0], tt8.columns[0]
> as x from tt7 left outer join tt8 on tt7.columns[0] = tt8.columns[0];
> DrillScreenRel
> DrillProjectRel(EXPR$0=[$1], x=[ITEM($2, 0)])
> DrillJoinRel(condition=[=($0, $3)], joinType=[left])
> DrillProjectRel($f2=[ITEM($0, 0)], ITEM=[ITEM($0, 0)])
> DrillScanRel(table=[[dfs, tmp, tt7]], groupscan=[EasyGroupScan
> [selectionRoot=file:/tmp/tt7, numFiles=1, columns=[`columns`[0]],
> files=[file:/tmp/tt7/0_0_0.csv]]])
> DrillProjectRel(columns=[$0], $f2=[ITEM($0, 0)])
> DrillScanRel(table=[[dfs, tmp, tt8]], groupscan=[EasyGroupScan
> [selectionRoot=file:/tmp/tt8, numFiles=1, columns=[`columns`, `columns`[0]],
> files=[file:/tmp/tt8/0_0_0.csv]]])
> {noformat}
> From what I can tell, the change in behavior occurred with CALCITE-1753;
> before that the ITEM was pushed on both sides of the Left Outer Join.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3349) Add Function DDL into SqlKind DDL enum
[ https://issues.apache.org/jira/browse/CALCITE-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhenqiu Huang reassigned CALCITE-3349: -- Assignee: Zhenqiu Huang > Add Function DDL into SqlKind DDL enum > -- > > Key: CALCITE-3349 > URL: https://issues.apache.org/jira/browse/CALCITE-3349 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Zhenqiu Huang >Assignee: Zhenqiu Huang >Priority: Minor > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 3h 20m > Remaining Estimate: 0h > > Currently, Create Function, Drop Function are not added into SqlKind DDL > enum. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-3358) Make Function DDLs implement SqlExecutableStatement
[ https://issues.apache.org/jira/browse/CALCITE-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhenqiu Huang reassigned CALCITE-3358: -- Assignee: Zhenqiu Huang > Make Function DDLs implement SqlExecutableStatement > --- > > Key: CALCITE-3358 > URL: https://issues.apache.org/jira/browse/CALCITE-3358 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Zhenqiu Huang >Assignee: Zhenqiu Huang >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-2204) Volcano Planner may not choose the cheapest cost plan
[ https://issues.apache.org/jira/browse/CALCITE-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haisheng Yuan resolved CALCITE-2204. Fix Version/s: 1.22.0 Resolution: Duplicate Fixed in https://github.com/apache/calcite/commit/e43595482617b1bb991407800c068a0c727e5c17 (CALCITE-3330) > Volcano Planner may not choose the cheapest cost plan > -- > > Key: CALCITE-2204 > URL: https://issues.apache.org/jira/browse/CALCITE-2204 > Project: Calcite > Issue Type: Bug >Reporter: LeoWangLZ >Assignee: Chunwei Lei >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > > Volcano Planner will propagate the cost improvement to parents that one of > the inputs has the best plan. But it not propagate to all parents firstly, it > propagate one parent and go to the parents of parent. In the way, if one > parent may propagate to other parent on the same level, and the cost maybe > less than others, but when propagate the parent again, it will not propagate > because the cost is already calculated, and it's can't be less then the cost > of the self. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3330) propagateCostImprovements() could result in stack overflow
[ https://issues.apache.org/jira/browse/CALCITE-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haisheng Yuan resolved CALCITE-3330. Fix Version/s: 1.22.0 Resolution: Fixed Fixed in https://github.com/apache/calcite/commit/e43595482617b1bb991407800c068a0c727e5c17. > propagateCostImprovements() could result in stack overflow > -- > > Key: CALCITE-3330 > URL: https://issues.apache.org/jira/browse/CALCITE-3330 > Project: Calcite > Issue Type: Bug >Reporter: Xiening Dai >Assignee: Xiening Dai >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Current implementation uses depth first approach for propagating cost > improvements to parent rel nodes. This could lead to stack overflow if the > rel node hierarchy is very deep. Suggest use breath first approach for cost > propagation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-3384) Support Kerberos-authentication using SPNEGO over HTTPS
[ https://issues.apache.org/jira/browse/CALCITE-3384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser reassigned CALCITE-3384: --- Assignee: István Tóth > Support Kerberos-authentication using SPNEGO over HTTPS > --- > > Key: CALCITE-3384 > URL: https://issues.apache.org/jira/browse/CALCITE-3384 > Project: Calcite > Issue Type: Improvement >Affects Versions: avatica-1.16.0 >Reporter: István Tóth >Assignee: István Tóth >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Avatica supports both HTTPS connections, and kerberos authentication using > SPNEGO, but not both at same. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3368) Some problems simplifying ‘expression IS NULL’
[
https://issues.apache.org/jira/browse/CALCITE-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3368:
Labels: pull-request-available (was: )
> Some problems simplifying ‘expression IS NULL’
> --
>
> Key: CALCITE-3368
> URL: https://issues.apache.org/jira/browse/CALCITE-3368
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Leonard Xu
>Assignee: Leonard Xu
>Priority: Major
> Labels: pull-request-available
>
> 'is null' expression in SQL may be optimized incorrectly in the underlying
> implementation.
>
> When I write a Fink SQL to test overflow just like
> {code:java}
> select
>case when (f0 + f1) is null then 'null' else 'not null' end
> from testTable
> {code}
> , I found expression '(f0 + f1) is null ' has been optimized by Calcite, and
> the optimization may be incorrect.
>
> The underlying implementation is that Calcite's simplification logic of
> isNull expression in SQL will convert from
> *"f(operand0, operand1) IS NULL"* to
> *"operand0 IS NULL OR operand1 IS NULL"* if the Policy of RexNode‘s SqlKind
> is ANY。
> This simplification leads to the expression will not calculate the real
> value of *f(operand0, operand1)* (eg.. '(f0 + f1)' in my case ），but '(f0 +
> f1)' maybe overflows after operation.
> {code:java}
> //org.apache.calcite.rex.RexSimplify.java
> private RexNode simplifyIsNull(RexNode a) {
> // Simplify the argument first,
> // call ourselves recursively to see whether we can make more progress.
> // For example, given
> // "(CASE WHEN FALSE THEN 1 ELSE 2) IS NULL" we first simplify the
> // argument to "2", and only then we can simplify "2 IS NULL" to "FALSE".
> a = simplify(a, UNKNOWN);
> if (!a.getType().isNullable() && isSafeExpression(a)) {
> return rexBuilder.makeLiteral(false);
> }
> if (RexUtil.isNull(a)) {
> return rexBuilder.makeLiteral(true);
> }
> if (a.getKind() == SqlKind.CAST) {
> return null;
> }
> switch (Strong.policy(a.getKind())) {
> case NOT_NULL:
> return rexBuilder.makeLiteral(false);
> case ANY:
> // "f" is a strong operator, so "f(operand0, operand1) IS NULL" simplifies
> // to "operand0 IS NULL OR operand1 IS NULL"
> final List operands = new ArrayList<>();
> for (RexNode operand : ((RexCall) a).getOperands()) {
> final RexNode simplified = simplifyIsNull(operand);
> if (simplified == null) {
> operands.add(
> rexBuilder.makeCall(SqlStdOperatorTable.IS_NULL, operand));
> } else {
> operands.add(simplified);
> }
> }
> return RexUtil.composeDisjunction(rexBuilder, operands, false);
> case AS_IS:
> default:
> return null;
> }
> }{code}
> And most of calculating SqlKinds are assigned *Policy.ANY* at present.
> {code:java}
> //org.apache.calcite.plan.Strong.java
> public static Policy policy(SqlKind kind) {
> return MAP.getOrDefault(kind, Policy.AS_IS);
> }
>
> map.put(SqlKind.PLUS, Policy.ANY);
> map.put(SqlKind.PLUS_PREFIX, Policy.ANY);
> map.put(SqlKind.MINUS, Policy.ANY);
> map.put(SqlKind.MINUS_PREFIX, Policy.ANY);
> map.put(SqlKind.TIMES, Policy.ANY);
> map.put(SqlKind.DIVIDE, Policy.ANY);
> * that operator evaluates to null. */
> public enum Policy {
> /** This kind of expression is never null. No need to look at its arguments,
>* if it has any. */
> NOT_NULL,
> /** This kind of expression has its own particular rules about whether it
>* is null. */
> CUSTOM,
> /** This kind of expression is null if and only if at least one of its
>* arguments is null. */
> ANY,
> /** This kind of expression may be null. There is no way to rewrite. */
> AS_IS,
> }{code}
>
> It may be an obvious nonequivalent simplification in SQL. And this issue come
> from Flink （FLINK-14030）.
> [~danny0405]， Could you have a look at this?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3395) add BuiltinMethod for Substring(String, int)
Youjun Yuan created CALCITE-3395: Summary: add BuiltinMethod for Substring(String, int) Key: CALCITE-3395 URL: https://issues.apache.org/jira/browse/CALCITE-3395 Project: Calcite Issue Type: Improvement Components: core Reporter: Youjun Yuan substring function has two versoins: 1, Substring(String, int, int) 2, Substring(String, int) currently in BuiltinMethod.java, only the first one is defined. Need to define the second one as well, so that we can use both of them. Apache Flink(FunctionGenerator.scala), reference the BuiltinMethod, since Calcite only defines 1, not 2, Flink always resolve SUBSTRING to Substring(String, int, int) even if there is only 2 parameters. This problem happens to be covered by method overloading of java, but it's still a potential problem. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3394) Can not register implementation of a UDF with RexImpTable and use the same with RelBuilder
Vaishnavee Kulkarni created CALCITE-3394:
Summary: Can not register implementation of a UDF with RexImpTable
and use the same with RelBuilder
Key: CALCITE-3394
URL: https://issues.apache.org/jira/browse/CALCITE-3394
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.21.0
Reporter: Vaishnavee Kulkarni
I am trying to register a simple UDF that returns the length of input string. I
can do this with prepareStatement approach -
{code:java}
public static class MyUdf1 {
public Integer eval(String a) {
return a.length();
}
}
public void testUDF() {
final String strLenSql = "select STRLEN('SampleString') from emp";
ScalarFunction strLenFunction = ScalarFunctionImpl.create(MyUdf1.class, "eval");
calciteConnection.getRootSchema().add("STRLEN", strLenFunction);
ResultSet resultSet =
calciteConnection.prepareStatement(strLenSql).executeQuery();
resultSet.next();
System.out.println(resultSet.getString(1));
}
{code}
When I try the similar steps with _RelBuilder_, I can successfully register the
_SqlOperator_; but am unable to refer to the implementation of this operator.
The builder refers to _RexImpTable_'s maps for the function table
implementation and there is no public/protected api exposed for these maps.
{code:java}
SqlFunction length = new SqlFunction("STRLEN",
SqlKind.OTHER_FUNCTION,
ReturnTypes.INTEGER,
null,
OperandTypes.STRING,
SqlFunctionCategory.USER_DEFINED_FUNCTION);
SqlStdOperatorTable sqlStdOperatorTable = SqlStdOperatorTable.instance();
sqlStdOperatorTable.register(length);
FrameworkConfig frameworkConfig = Frameworks.newConfigBuilder()
.parserConfig(SqlParser.Config.DEFAULT)
.defaultSchema(connection.getRootSchema().getSubSchema("SYSTEM"))
.programs(Programs.sequence(Programs.ofRules(Programs.RULE_SET),
Programs.CALC_PROGRAM))
.operatorTable(sqlStdOperatorTable)
.build();
final RelBuilder builder = RelBuilder.create(frameworkConfig);
RelNode udfRelNode = builder
.scan("EMP")
.project(builder.call(length,builder.literal("SampleString")))
.build();
ResultSet resultSet = RelRunners.run(udfRelNode).executeQuery();
{code}
This code throws exception -
{code:java}
Caused by: java.lang.RuntimeException: cannot translate call STRLEN($t3)Caused
by: java.lang.RuntimeException: cannot translate call STRLEN($t3) at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translateCall(RexToLixTranslator.java:756)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:730)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate(RexToLixTranslator.java:199)
at
org.apache.calcite.adapter.enumerable.RexToLixTranslator.translate0(RexToLixTranslator.java:684)
{code}
There are no junits that show this working with _RelBuilder_. Is it possible
currently to register and use the udfs with RelBuilder?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3368) Some problems simplifying ‘expression IS NULL’
[
https://issues.apache.org/jira/browse/CALCITE-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947635#comment-16947635
]
Danny Chen commented on CALCITE-3368:
-
Thanks for taking this issue, [~Leonard Xu] !
> Some problems simplifying ‘expression IS NULL’
> --
>
> Key: CALCITE-3368
> URL: https://issues.apache.org/jira/browse/CALCITE-3368
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Leonard Xu
>Assignee: Leonard Xu
>Priority: Major
>
> 'is null' expression in SQL may be optimized incorrectly in the underlying
> implementation.
>
> When I write a Fink SQL to test overflow just like
> {code:java}
> select
>case when (f0 + f1) is null then 'null' else 'not null' end
> from testTable
> {code}
> , I found expression '(f0 + f1) is null ' has been optimized by Calcite, and
> the optimization may be incorrect.
>
> The underlying implementation is that Calcite's simplification logic of
> isNull expression in SQL will convert from
> *"f(operand0, operand1) IS NULL"* to
> *"operand0 IS NULL OR operand1 IS NULL"* if the Policy of RexNode‘s SqlKind
> is ANY。
> This simplification leads to the expression will not calculate the real
> value of *f(operand0, operand1)* (eg.. '(f0 + f1)' in my case ），but '(f0 +
> f1)' maybe overflows after operation.
> {code:java}
> //org.apache.calcite.rex.RexSimplify.java
> private RexNode simplifyIsNull(RexNode a) {
> // Simplify the argument first,
> // call ourselves recursively to see whether we can make more progress.
> // For example, given
> // "(CASE WHEN FALSE THEN 1 ELSE 2) IS NULL" we first simplify the
> // argument to "2", and only then we can simplify "2 IS NULL" to "FALSE".
> a = simplify(a, UNKNOWN);
> if (!a.getType().isNullable() && isSafeExpression(a)) {
> return rexBuilder.makeLiteral(false);
> }
> if (RexUtil.isNull(a)) {
> return rexBuilder.makeLiteral(true);
> }
> if (a.getKind() == SqlKind.CAST) {
> return null;
> }
> switch (Strong.policy(a.getKind())) {
> case NOT_NULL:
> return rexBuilder.makeLiteral(false);
> case ANY:
> // "f" is a strong operator, so "f(operand0, operand1) IS NULL" simplifies
> // to "operand0 IS NULL OR operand1 IS NULL"
> final List operands = new ArrayList<>();
> for (RexNode operand : ((RexCall) a).getOperands()) {
> final RexNode simplified = simplifyIsNull(operand);
> if (simplified == null) {
> operands.add(
> rexBuilder.makeCall(SqlStdOperatorTable.IS_NULL, operand));
> } else {
> operands.add(simplified);
> }
> }
> return RexUtil.composeDisjunction(rexBuilder, operands, false);
> case AS_IS:
> default:
> return null;
> }
> }{code}
> And most of calculating SqlKinds are assigned *Policy.ANY* at present.
> {code:java}
> //org.apache.calcite.plan.Strong.java
> public static Policy policy(SqlKind kind) {
> return MAP.getOrDefault(kind, Policy.AS_IS);
> }
>
> map.put(SqlKind.PLUS, Policy.ANY);
> map.put(SqlKind.PLUS_PREFIX, Policy.ANY);
> map.put(SqlKind.MINUS, Policy.ANY);
> map.put(SqlKind.MINUS_PREFIX, Policy.ANY);
> map.put(SqlKind.TIMES, Policy.ANY);
> map.put(SqlKind.DIVIDE, Policy.ANY);
> * that operator evaluates to null. */
> public enum Policy {
> /** This kind of expression is never null. No need to look at its arguments,
>* if it has any. */
> NOT_NULL,
> /** This kind of expression has its own particular rules about whether it
>* is null. */
> CUSTOM,
> /** This kind of expression is null if and only if at least one of its
>* arguments is null. */
> ANY,
> /** This kind of expression may be null. There is no way to rewrite. */
> AS_IS,
> }{code}
>
> It may be an obvious nonequivalent simplification in SQL. And this issue come
> from Flink （FLINK-14030）.
> [~danny0405]， Could you have a look at this?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3393) RelStructuredTypeFlattener: improve support for functions with struct input
Igor Guzenko created CALCITE-3393:
-
Summary: RelStructuredTypeFlattener: improve support for functions
with struct input
Key: CALCITE-3393
URL: https://issues.apache.org/jira/browse/CALCITE-3393
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Igor Guzenko
Assignee: Igor Guzenko
1.
[RelStructuredTypeFlattener|https://github.com/apache/calcite/blob/148bfd329413c0272395cc0b7c322b3c5a34b667/core/src/main/java/org/apache/calcite/sql2rel/RelStructuredTypeFlattener.java#L376]
doesn't support aggregate functions for struct type column.
Example test case:
{code:java}
@Test
public void testAggregateFunctionWithStructInput() {
final String sql =
"select count(dn.skill) from sales.dept_nested dn";
sql(sql).ok();
}
{code}
2. For other functions, except ITEM, flattener uses first nested primitive
field from
original struct input. Example test case:
{code:java}
@Test
public void testFunctionWithStructInput() {
final String sql =
"select json_type(dn.skill) from sales.dept_nested dn";
sql(sql).ok();
}
{code}
Generated plan:
{code}
LogicalProject(EXPR$0=[JSON_TYPE($2.TYPE)])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3368) Some problems simplifying ‘expression IS NULL’
[
https://issues.apache.org/jira/browse/CALCITE-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen reassigned CALCITE-3368:
---
Assignee: Leonard Xu (was: Danny Chen)
> Some problems simplifying ‘expression IS NULL’
> --
>
> Key: CALCITE-3368
> URL: https://issues.apache.org/jira/browse/CALCITE-3368
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Leonard Xu
>Assignee: Leonard Xu
>Priority: Major
>
> 'is null' expression in SQL may be optimized incorrectly in the underlying
> implementation.
>
> When I write a Fink SQL to test overflow just like
> {code:java}
> select
>case when (f0 + f1) is null then 'null' else 'not null' end
> from testTable
> {code}
> , I found expression '(f0 + f1) is null ' has been optimized by Calcite, and
> the optimization may be incorrect.
>
> The underlying implementation is that Calcite's simplification logic of
> isNull expression in SQL will convert from
> *"f(operand0, operand1) IS NULL"* to
> *"operand0 IS NULL OR operand1 IS NULL"* if the Policy of RexNode‘s SqlKind
> is ANY。
> This simplification leads to the expression will not calculate the real
> value of *f(operand0, operand1)* (eg.. '(f0 + f1)' in my case ），but '(f0 +
> f1)' maybe overflows after operation.
> {code:java}
> //org.apache.calcite.rex.RexSimplify.java
> private RexNode simplifyIsNull(RexNode a) {
> // Simplify the argument first,
> // call ourselves recursively to see whether we can make more progress.
> // For example, given
> // "(CASE WHEN FALSE THEN 1 ELSE 2) IS NULL" we first simplify the
> // argument to "2", and only then we can simplify "2 IS NULL" to "FALSE".
> a = simplify(a, UNKNOWN);
> if (!a.getType().isNullable() && isSafeExpression(a)) {
> return rexBuilder.makeLiteral(false);
> }
> if (RexUtil.isNull(a)) {
> return rexBuilder.makeLiteral(true);
> }
> if (a.getKind() == SqlKind.CAST) {
> return null;
> }
> switch (Strong.policy(a.getKind())) {
> case NOT_NULL:
> return rexBuilder.makeLiteral(false);
> case ANY:
> // "f" is a strong operator, so "f(operand0, operand1) IS NULL" simplifies
> // to "operand0 IS NULL OR operand1 IS NULL"
> final List operands = new ArrayList<>();
> for (RexNode operand : ((RexCall) a).getOperands()) {
> final RexNode simplified = simplifyIsNull(operand);
> if (simplified == null) {
> operands.add(
> rexBuilder.makeCall(SqlStdOperatorTable.IS_NULL, operand));
> } else {
> operands.add(simplified);
> }
> }
> return RexUtil.composeDisjunction(rexBuilder, operands, false);
> case AS_IS:
> default:
> return null;
> }
> }{code}
> And most of calculating SqlKinds are assigned *Policy.ANY* at present.
> {code:java}
> //org.apache.calcite.plan.Strong.java
> public static Policy policy(SqlKind kind) {
> return MAP.getOrDefault(kind, Policy.AS_IS);
> }
>
> map.put(SqlKind.PLUS, Policy.ANY);
> map.put(SqlKind.PLUS_PREFIX, Policy.ANY);
> map.put(SqlKind.MINUS, Policy.ANY);
> map.put(SqlKind.MINUS_PREFIX, Policy.ANY);
> map.put(SqlKind.TIMES, Policy.ANY);
> map.put(SqlKind.DIVIDE, Policy.ANY);
> * that operator evaluates to null. */
> public enum Policy {
> /** This kind of expression is never null. No need to look at its arguments,
>* if it has any. */
> NOT_NULL,
> /** This kind of expression has its own particular rules about whether it
>* is null. */
> CUSTOM,
> /** This kind of expression is null if and only if at least one of its
>* arguments is null. */
> ANY,
> /** This kind of expression may be null. There is no way to rewrite. */
> AS_IS,
> }{code}
>
> It may be an obvious nonequivalent simplification in SQL. And this issue come
> from Flink （FLINK-14030）.
> [~danny0405]， Could you have a look at this?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2221) RelRoot.project does not take into account flattened record type
[
https://issues.apache.org/jira/browse/CALCITE-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16947598#comment-16947598
]
Danny Chen commented on CALCITE-2221:
-
Thanks for the reminder [~IhorHuzenko] !
> RelRoot.project does not take into account flattened record type
>
>
> Key: CALCITE-2221
> URL: https://issues.apache.org/jira/browse/CALCITE-2221
> Project: Calcite
> Issue Type: Task
> Components: core
>Reporter: Shuyi Chen
>Assignee: Igor Guzenko
>Priority: Major
> Fix For: 1.21.0
>
>
> To reproduce, simply run:
> @Test public void testFlattenRecords() {
> sql("select employees[1] from dept_nested").ok();
> }
> It will yield:
> LogicalProject(EXPR$0=[$0])
> LogicalProject(EXPR$0$0=[ITEM($2, 1).EMPNO], EXPR$0$1=[ITEM($2, 1).ENAME],
> EXPR$0$2=[ITEM($2, 1).DETAIL])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3392) Column expression in DDL should be validated before converting to RexNode
[ https://issues.apache.org/jira/browse/CALCITE-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3392: Labels: pull-request-available (was: ) > Column expression in DDL should be validated before converting to RexNode > - > > Key: CALCITE-3392 > URL: https://issues.apache.org/jira/browse/CALCITE-3392 > Project: Calcite > Issue Type: Sub-task > Components: core >Affects Versions: 1.21.0 >Reporter: Danny Chen >Assignee: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > > As described in CALCITE-3379, we should validate the column expression so > that the expression can be converted correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3392) Column expression in DDL should be validated before converting to RexNode
Danny Chen created CALCITE-3392: --- Summary: Column expression in DDL should be validated before converting to RexNode Key: CALCITE-3392 URL: https://issues.apache.org/jira/browse/CALCITE-3392 Project: Calcite Issue Type: Sub-task Components: core Affects Versions: 1.21.0 Reporter: Danny Chen Assignee: Danny Chen Fix For: 1.22.0 As described in CALCITE-3379, we should validate the column expression so that the expression can be converted correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-2221) RelRoot.project does not take into account flattened record type
[
https://issues.apache.org/jira/browse/CALCITE-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Guzenko resolved CALCITE-2221.
---
Fix Version/s: 1.21.0
Resolution: Fixed
Fixed in scope of CALCITE-3138. Plan for test case described in the ticket now
uses ROW constructor function to represent final projected value.
{code}
LogicalProject(EXPR$0=[ROW(ITEM($3, 1).EMPNO, ITEM($3, 1).ENAME, ROW(ITEM($3,
1).DETAIL.SKILLS))])
LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
{code}
> RelRoot.project does not take into account flattened record type
>
>
> Key: CALCITE-2221
> URL: https://issues.apache.org/jira/browse/CALCITE-2221
> Project: Calcite
> Issue Type: Task
> Components: core
>Reporter: Shuyi Chen
>Assignee: Igor Guzenko
>Priority: Major
> Fix For: 1.21.0
>
>
> To reproduce, simply run:
> @Test public void testFlattenRecords() {
> sql("select employees[1] from dept_nested").ok();
> }
> It will yield:
> LogicalProject(EXPR$0=[$0])
> LogicalProject(EXPR$0$0=[ITEM($2, 1).EMPNO], EXPR$0$1=[ITEM($2, 1).ENAME],
> EXPR$0$2=[ITEM($2, 1).DETAIL])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-2221) RelRoot.project does not take into account flattened record type
[
https://issues.apache.org/jira/browse/CALCITE-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Guzenko reassigned CALCITE-2221:
-
Assignee: Igor Guzenko
> RelRoot.project does not take into account flattened record type
>
>
> Key: CALCITE-2221
> URL: https://issues.apache.org/jira/browse/CALCITE-2221
> Project: Calcite
> Issue Type: Task
> Components: core
>Reporter: Shuyi Chen
>Assignee: Igor Guzenko
>Priority: Major
>
> To reproduce, simply run:
> @Test public void testFlattenRecords() {
> sql("select employees[1] from dept_nested").ok();
> }
> It will yield:
> LogicalProject(EXPR$0=[$0])
> LogicalProject(EXPR$0$0=[ITEM($2, 1).EMPNO], EXPR$0$1=[ITEM($2, 1).ENAME],
> EXPR$0$2=[ITEM($2, 1).DETAIL])
> LogicalTableScan(table=[[CATALOG, SALES, DEPT_NESTED]])
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-2963) IndexOutOfBoundsException in RelStructuredTypeFlattener when accessing nested fields
[
https://issues.apache.org/jira/browse/CALCITE-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Guzenko resolved CALCITE-2963.
---
Fix Version/s: 1.21.0
Assignee: Igor Guzenko
Resolution: Fixed
Fixed in scope of CALCITE-3138.
> IndexOutOfBoundsException in RelStructuredTypeFlattener when accessing nested
> fields
>
>
> Key: CALCITE-2963
> URL: https://issues.apache.org/jira/browse/CALCITE-2963
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.19.0
>Reporter: Will Yu
>Assignee: Igor Guzenko
>Priority: Minor
> Fix For: 1.21.0
>
>
> When accessing nested field in a STRUCTURED SqlType, sometimes
> RelStructuredTypeFlattener will crash with java.lang.IndexOutOfBoundsException
> The test case is in SqlToRelConverterTest.java
> @Test
> public void testNestedColumnCrash() {
> final String sql =
> "select mailing_address.zip from sales.emp_address where home_address.city =
> 'abc'";
> sql(sql).ok();
> }
>
> The root cause is that when generate new RelNode for old RelNode, we did not
> consider whether the flattened field list needs null indicator.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
