[jira] [Updated] (CALCITE-3415) Cannot parse REGEXP_SUBSTR in BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pranay Parmar updated CALCITE-3415:
---
Fix Version/s: (was: 1.22.0)
> Cannot parse REGEXP_SUBSTR in BigQuery
> --
>
> Key: CALCITE-3415
> URL: https://issues.apache.org/jira/browse/CALCITE-3415
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Pranay Parmar
>Priority: Minor
>
> REGEXP_SUBSTR error :
> {code:java}
> No match found for function signature REGEXP_SUBSTR(, ,
> [, , ]){code}
>
> Example query:
> {code:sql}
> SELECT REGEXP_SUBSTR('chocolate Chip cookies', 'c+.{2}', 1, product_id, 'i')
> FROM public.account{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3415) Cannot parse REGEXP_SUBSTR in BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pranay Parmar updated CALCITE-3415:
---
Labels: pull-request-available (was: )
> Cannot parse REGEXP_SUBSTR in BigQuery
> --
>
> Key: CALCITE-3415
> URL: https://issues.apache.org/jira/browse/CALCITE-3415
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Pranay Parmar
>Priority: Minor
> Labels: pull-request-available
>
> REGEXP_SUBSTR error :
> {code:java}
> No match found for function signature REGEXP_SUBSTR(, ,
> [, , ]){code}
>
> Example query:
> {code:sql}
> SELECT REGEXP_SUBSTR('chocolate Chip cookies', 'c+.{2}', 1, product_id, 'i')
> FROM public.account{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3415) Cannot parse REGEXP_SUBSTR in BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pranay Parmar updated CALCITE-3415:
---
Affects Version/s: 1.21.0
> Cannot parse REGEXP_SUBSTR in BigQuery
> --
>
> Key: CALCITE-3415
> URL: https://issues.apache.org/jira/browse/CALCITE-3415
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Pranay Parmar
>Priority: Minor
>
> REGEXP_SUBSTR error :
> {code:java}
> No match found for function signature REGEXP_SUBSTR(, ,
> [, , ]){code}
>
> Example query:
> {code:sql}
> SELECT REGEXP_SUBSTR('chocolate Chip cookies', 'c+.{2}', 1, product_id, 'i')
> FROM public.account{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3414) Unify Expression'type cast and conversion as a robust one
[
https://issues.apache.org/jira/browse/CALCITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952491#comment-16952491
]
Feng Zhu commented on CALCITE-3414:
---
[~danny0405], there are two reasons:
(1)some implementation in Types.castIfNecessary is not correct;
(2)we just need to copy a small part of unique logics, mainly
{color:#FF}_returnType instanceof RecordType_{color} and{color:#FF}
_Types.isAssignableFrom(returnType, type)_{color}, For other parts,
RexToLixTranslator is more powerful.
> Unify Expression'type cast and conversion as a robust one
> -
>
> Key: CALCITE-3414
> URL: https://issues.apache.org/jira/browse/CALCITE-3414
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Attachments: RexToLixTranslator.png, TypeConversion.txt, Types.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current now, there are two functions in calcite that can be used to
> cast/convert Expression to a specific Type.
> *_Types.castIfNecessary_* and _*RexToLixTranslator.convert*_.
> We make a deep investigation on their implementations and demonstrate them as
> below.
> {color:#ff}
> !RexToLixTranslator.png!{color}
> {color:#ff}
> *RexToLixTranslator.convert*{color}
> !Types.png!
> {color:#ff}
> *Types.castIfNecessary*{color}
> It can be seen that:
> (1) They have a lot of overlaps;
> (2) *_RexToLixTranslator.cast_* can cover more cases with tools like
> _SqlFunctions_ and etc.
> (3) Both of them have limitations and may generate incorrect code, which is
> listed in attachment(TypeConversion.txt).
> Multiple choices usually bring confusion to developers and resulting to the
> misuse of them.
> For example, CALCITE-3245 exposes that Types.castIfNecessary cannot cast the
> Expression to BigDecimal.class.
> Fixing the issue in *_Types.castIfNecessary_* directly seems to be not a
> good idea.
> On one hand, it is not convenient to call _SqlFunctions_ in linq4j. One the
> other hand, it will brings duplicate with _*RexToLixTranslator.cast*_.
> However, due to some unique logic in _*Types.castIfNecessary*_, we cannot
> replace it as _*RexToLixTranslator.cast*_ neither.
> Therefore, it is a good idea to integrate implementations into
> RexToLixTranslator.cast.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3412) Response Error for FLOOR TIMESTAMP TO WEEK
[
https://issues.apache.org/jira/browse/CALCITE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952489#comment-16952489
]
Danny Chen commented on CALCITE-3412:
-
I didn't find any engine to support 'FLOOR(... TO XXX)' [1][2], this is the
grammar i found in SQL standard 2011:
{code:sql}
::=
FLOOR
::=
|
|
{code}
[1] https://docs.oracle.com/cd/B19306_01/server.102/b14200/functions058.htm
[2]
https://docs.microsoft.com/en-us/sql/t-sql/functions/floor-transact-sql?view=sql-server-ver15
> Response Error for FLOOR TIMESTAMP TO WEEK
> ---
>
> Key: CALCITE-3412
> URL: https://issues.apache.org/jira/browse/CALCITE-3412
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: mac,linux
>Reporter: huaicui
>Priority: Major
> Attachments: image-2019-10-15-13-33-34-896.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Floor timestamp to week exist error:
> The start day of the week is not Sunday or Monday, calcite use Thursday to
> split a week.
> Example:
> sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
> Response:
> 2017-01-26 00:00:00.0
>
> 2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
> the first day that we expect.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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=16952482#comment-16952482
]
Julian Hyde commented on CALCITE-3300:
--
Sorry I didn't reply. I am very busy.
> 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
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[jira] [Commented] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952481#comment-16952481 ] Danny Chen commented on CALCITE-1075: - I think it is because internally Calcite use Long to represent the datetime data type values, including DATE and TIMESTAMP. > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at testPs.TestPs.main(TestPs.java:150) > > 3. UDFs with same name and different arg types > UDF： DATE_TRUNC（Timestamp D, String x） returns a timestamp value > DATE_TRUNC(Date D, String x) returns a date value > > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > Error stack： > Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, > column 11 to line 1, column 32: Cannot apply 'DATE_TRUNC' to arguments of > type 'DATE_TRUNC(, )'. Supported form(s): > 'DATE_TRUNC(, )' > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:715) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:703) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:3932) > at > org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:275) > at > org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:92) > at >
[jira] [Commented] (CALCITE-3414) Unify Expression'type cast and conversion as a robust one
[
https://issues.apache.org/jira/browse/CALCITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952480#comment-16952480
]
Danny Chen commented on CALCITE-3414:
-
Thanks Julian for clarifying the strategy, then i think keep
Types.castIfNecessary in linq4j is the right way to choose, but we should give
more doc to it and states that in which case it can be used.
Instead of copy code from Types.castIfNecessary into
RexToLixTranslator.convert, why not reuse and invoke Types.castIfNecessary
directly from inside RexToLixTranslator.convert ?
> Unify Expression'type cast and conversion as a robust one
> -
>
> Key: CALCITE-3414
> URL: https://issues.apache.org/jira/browse/CALCITE-3414
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Attachments: RexToLixTranslator.png, TypeConversion.txt, Types.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current now, there are two functions in calcite that can be used to
> cast/convert Expression to a specific Type.
> *_Types.castIfNecessary_* and _*RexToLixTranslator.convert*_.
> We make a deep investigation on their implementations and demonstrate them as
> below.
> {color:#ff}
> !RexToLixTranslator.png!{color}
> {color:#ff}
> *RexToLixTranslator.convert*{color}
> !Types.png!
> {color:#ff}
> *Types.castIfNecessary*{color}
> It can be seen that:
> (1) They have a lot of overlaps;
> (2) *_RexToLixTranslator.cast_* can cover more cases with tools like
> _SqlFunctions_ and etc.
> (3) Both of them have limitations and may generate incorrect code, which is
> listed in attachment(TypeConversion.txt).
> Multiple choices usually bring confusion to developers and resulting to the
> misuse of them.
> For example, CALCITE-3245 exposes that Types.castIfNecessary cannot cast the
> Expression to BigDecimal.class.
> Fixing the issue in *_Types.castIfNecessary_* directly seems to be not a
> good idea.
> On one hand, it is not convenient to call _SqlFunctions_ in linq4j. One the
> other hand, it will brings duplicate with _*RexToLixTranslator.cast*_.
> However, due to some unique logic in _*Types.castIfNecessary*_, we cannot
> replace it as _*RexToLixTranslator.cast*_ neither.
> Therefore, it is a good idea to integrate implementations into
> RexToLixTranslator.cast.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[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=16952476#comment-16952476 ] Julian Hyde commented on CALCITE-3395: -- [~yuanyoujun], There are a few cases where we do code generation for functions that are overloaded. We don't check that the arguments match the parameter types of the method. It's not totally kosher but we get away with it, and I'm not too worried. The main goal of BuiltInMethod is impact analysis (finding all the places that we generate calls to String.substring) and for that it works. > 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] [Comment Edited] (CALCITE-3368) PLUS, MUNUS and TIMES should be unsafe when simplifying ‘expression IS NULL’
[
https://issues.apache.org/jira/browse/CALCITE-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952471#comment-16952471
]
Danny Chen edited comment on CALCITE-3368 at 10/16/19 3:14 AM:
---
I tested these queries in MYSQL 5.6 and MS-SQL 2017:
{code:sql}
select -2147483648/0.25 from t; -- returns -8589934592
select -2147483648/0 from t; -- returns null ORACLE and MS-SQL throws exception
select 2147483647 + 2147483647 from t; -- returns 4294967294
select -2147483648 + -2147483648 from t; -- returns -4294967296
select -2147483648 * 2147483647 from t; -- returns -4611686016279904000
{code}
was (Author: danny0405):
I tested these queries in MYSQL 5.6:
{code:sql}
select -2147483648/0.25 from t; -- returns -8589934592
select -2147483648/0 from t; -- returns null ORACLE and MS-SQL throws exception
select 2147483647 + 2147483647 from t; -- returns 4294967294
select -2147483648 + -2147483648 from t; -- returns -4294967296
select -2147483648 * 2147483647 from t; -- returns -4611686016279904000
{code}
> PLUS, MUNUS and TIMES should be unsafe when 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
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> '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
[jira] [Updated] (CALCITE-3399) Field-pruning for set operators (except UNION ALL) changes query semantics
[
https://issues.apache.org/jira/browse/CALCITE-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jin xing updated CALCITE-3399:
--
Summary: Field-pruning for set operators (except UNION ALL) changes query
semantics (was: RelFieldTrimmer trim fields for UNION, INTERSECT, INTERSECT
ALL, EXCEPT, EXCEPT ALL)
> Field-pruning for set operators (except UNION ALL) changes query semantics
> --
>
> Key: CALCITE-3399
> URL: https://issues.apache.org/jira/browse/CALCITE-3399
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jin xing
>Assignee: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *RelFieldTrimmer#trimFields* provides functionality to trim fields for
> *UNION, UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL;*
> But *UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL* works by
> checking duplication. Column pruning on inputs of *SetOp* might lead to
> different semantics.
>
> Take below example for illustration
> {code:java}
> emp0:
> name, deptno
> "A", 0
> "B", 1
> emp1:
> name, deptno
> "C", 0
> "D", 2
> select deptno from
> (select name, deptno from emp0
> intersect
> select name, deptno from emp1)
> {code}
> Run above Sql on emp0 and emp1, result is not empty if trim fields on inputs
> of INTERSECT, but result is empty if DO NOT trim fields on inputs of INTERSECT
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3399) RelFieldTrimmer trim fields for UNION, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL
[
https://issues.apache.org/jira/browse/CALCITE-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952472#comment-16952472
]
jin xing commented on CALCITE-3399:
---
[~julianhyde]
That would be much better ~
Thanks a lot ~
I will update the PR title and commit message soon ~
> RelFieldTrimmer trim fields for UNION, INTERSECT, INTERSECT ALL, EXCEPT,
> EXCEPT ALL
> ---
>
> Key: CALCITE-3399
> URL: https://issues.apache.org/jira/browse/CALCITE-3399
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jin xing
>Assignee: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *RelFieldTrimmer#trimFields* provides functionality to trim fields for
> *UNION, UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL;*
> But *UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL* works by
> checking duplication. Column pruning on inputs of *SetOp* might lead to
> different semantics.
>
> Take below example for illustration
> {code:java}
> emp0:
> name, deptno
> "A", 0
> "B", 1
> emp1:
> name, deptno
> "C", 0
> "D", 2
> select deptno from
> (select name, deptno from emp0
> intersect
> select name, deptno from emp1)
> {code}
> Run above Sql on emp0 and emp1, result is not empty if trim fields on inputs
> of INTERSECT, but result is empty if DO NOT trim fields on inputs of INTERSECT
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3368) PLUS, MUNUS and TIMES should be unsafe when simplifying ‘expression IS NULL’
[
https://issues.apache.org/jira/browse/CALCITE-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952471#comment-16952471
]
Danny Chen commented on CALCITE-3368:
-
I tested these queries in MYSQL 5.6:
{code:sql}
select -2147483648/0.25 from t; -- returns -8589934592
select -2147483648/0 from t; -- returns null ORACLE and MS-SQL throws exception
select 2147483647 + 2147483647 from t; -- returns 4294967294
select -2147483648 + -2147483648 from t; -- returns -4294967296
select -2147483648 * 2147483647 from t; -- returns -4611686016279904000
{code}
> PLUS, MUNUS and TIMES should be unsafe when 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
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> '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] [Comment Edited] (CALCITE-3414) Unify Expression'type cast and conversion as a robust one
[
https://issues.apache.org/jira/browse/CALCITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952470#comment-16952470
]
Feng Zhu edited comment on CALCITE-3414 at 10/16/19 3:09 AM:
-
Hi, [~julianhyde] , thanks for your clarification on the role of these two
functions.
Current _Types.castIfNecessary_ implementation has no constraint on what it
can do and consequently it "can" handle everything, even the result is wrong.
Hence, from my personal view, it is not suitable to call Types.castIfNecessary
in Calcite-core, because it involves types like BigDecimal/Date and etc.
The main approach of this PR is:
(1) copy some unique logic for special cases in Types.castIfNecessary into
RexToLixTranslator.convert, making it .
(2) unify the entrance of type cast/convert in Calcite-core as
RexToLixTranslator.convert.
was (Author: donnyzone):
Hi, [~julianhyde] , thanks for your clarification on the role of these two
functions.
Current _Types.castIfNecessary_ implementation has no constraint on what it can
do and consequently it can handle everything, even the result is wrong.
Hence, from my personal view, it is not suitable to call Types.castIfNecessary
in Calcite-core, because it involves types like BigDecimal/Date and etc.
The main approach of this PR is:
(1) copy some unique logic for special cases in Types.castIfNecessary into
RexToLixTranslator.convert, making it .
(2) unify the entrance of type cast/convert in Calcite-core as
RexToLixTranslator.convert.
> Unify Expression'type cast and conversion as a robust one
> -
>
> Key: CALCITE-3414
> URL: https://issues.apache.org/jira/browse/CALCITE-3414
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Attachments: RexToLixTranslator.png, TypeConversion.txt, Types.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current now, there are two functions in calcite that can be used to
> cast/convert Expression to a specific Type.
> *_Types.castIfNecessary_* and _*RexToLixTranslator.convert*_.
> We make a deep investigation on their implementations and demonstrate them as
> below.
> {color:#ff}
> !RexToLixTranslator.png!{color}
> {color:#ff}
> *RexToLixTranslator.convert*{color}
> !Types.png!
> {color:#ff}
> *Types.castIfNecessary*{color}
> It can be seen that:
> (1) They have a lot of overlaps;
> (2) *_RexToLixTranslator.cast_* can cover more cases with tools like
> _SqlFunctions_ and etc.
> (3) Both of them have limitations and may generate incorrect code, which is
> listed in attachment(TypeConversion.txt).
> Multiple choices usually bring confusion to developers and resulting to the
> misuse of them.
> For example, CALCITE-3245 exposes that Types.castIfNecessary cannot cast the
> Expression to BigDecimal.class.
> Fixing the issue in *_Types.castIfNecessary_* directly seems to be not a
> good idea.
> On one hand, it is not convenient to call _SqlFunctions_ in linq4j. One the
> other hand, it will brings duplicate with _*RexToLixTranslator.cast*_.
> However, due to some unique logic in _*Types.castIfNecessary*_, we cannot
> replace it as _*RexToLixTranslator.cast*_ neither.
> Therefore, it is a good idea to integrate implementations into
> RexToLixTranslator.cast.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3414) Unify Expression'type cast and conversion as a robust one
[
https://issues.apache.org/jira/browse/CALCITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952470#comment-16952470
]
Feng Zhu commented on CALCITE-3414:
---
Hi, [~julianhyde] , thanks for your clarification on the role of these two
functions.
Current _Types.castIfNecessary_ implementation has no constraint on what it can
do and consequently it can handle everything, even the result is wrong.
Hence, from my personal view, it is not suitable to call Types.castIfNecessary
in Calcite-core, because it involves types like BigDecimal/Date and etc.
The main approach of this PR is:
(1) copy some unique logic for special cases in Types.castIfNecessary into
RexToLixTranslator.convert, making it .
(2) unify the entrance of type cast/convert in Calcite-core as
RexToLixTranslator.convert.
> Unify Expression'type cast and conversion as a robust one
> -
>
> Key: CALCITE-3414
> URL: https://issues.apache.org/jira/browse/CALCITE-3414
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Attachments: RexToLixTranslator.png, TypeConversion.txt, Types.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current now, there are two functions in calcite that can be used to
> cast/convert Expression to a specific Type.
> *_Types.castIfNecessary_* and _*RexToLixTranslator.convert*_.
> We make a deep investigation on their implementations and demonstrate them as
> below.
> {color:#ff}
> !RexToLixTranslator.png!{color}
> {color:#ff}
> *RexToLixTranslator.convert*{color}
> !Types.png!
> {color:#ff}
> *Types.castIfNecessary*{color}
> It can be seen that:
> (1) They have a lot of overlaps;
> (2) *_RexToLixTranslator.cast_* can cover more cases with tools like
> _SqlFunctions_ and etc.
> (3) Both of them have limitations and may generate incorrect code, which is
> listed in attachment(TypeConversion.txt).
> Multiple choices usually bring confusion to developers and resulting to the
> misuse of them.
> For example, CALCITE-3245 exposes that Types.castIfNecessary cannot cast the
> Expression to BigDecimal.class.
> Fixing the issue in *_Types.castIfNecessary_* directly seems to be not a
> good idea.
> On one hand, it is not convenient to call _SqlFunctions_ in linq4j. One the
> other hand, it will brings duplicate with _*RexToLixTranslator.cast*_.
> However, due to some unique logic in _*Types.castIfNecessary*_, we cannot
> replace it as _*RexToLixTranslator.cast*_ neither.
> Therefore, it is a good idea to integrate implementations into
> RexToLixTranslator.cast.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3414) Unify Expression'type cast and conversion as a robust one
[
https://issues.apache.org/jira/browse/CALCITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952468#comment-16952468
]
Feng Zhu commented on CALCITE-3414:
---
Hi, [~danny0405], we find both of them have limitations. If we use
*RexToLixTranslator#covert* as the fallback of *Types#castIfNecessary*, we
can't get expected result in some cases, because it will not "fall".
For example:
{code:java}
Case 1: int -> Byte
Type.castIfNecessary: (byte) x // byte is not Byte, resulting
un-deterministic{code}
{code:java}
Case 2: int ->String
Type.castIfNecessary: (String) x // Compilation error, "inconvetable
types"{code}
But if we fix the issue in *Types#castIfNecessary*, we will need to maintain
two piece of code.
> Unify Expression'type cast and conversion as a robust one
> -
>
> Key: CALCITE-3414
> URL: https://issues.apache.org/jira/browse/CALCITE-3414
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Attachments: RexToLixTranslator.png, TypeConversion.txt, Types.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current now, there are two functions in calcite that can be used to
> cast/convert Expression to a specific Type.
> *_Types.castIfNecessary_* and _*RexToLixTranslator.convert*_.
> We make a deep investigation on their implementations and demonstrate them as
> below.
> {color:#ff}
> !RexToLixTranslator.png!{color}
> {color:#ff}
> *RexToLixTranslator.convert*{color}
> !Types.png!
> {color:#ff}
> *Types.castIfNecessary*{color}
> It can be seen that:
> (1) They have a lot of overlaps;
> (2) *_RexToLixTranslator.cast_* can cover more cases with tools like
> _SqlFunctions_ and etc.
> (3) Both of them have limitations and may generate incorrect code, which is
> listed in attachment(TypeConversion.txt).
> Multiple choices usually bring confusion to developers and resulting to the
> misuse of them.
> For example, CALCITE-3245 exposes that Types.castIfNecessary cannot cast the
> Expression to BigDecimal.class.
> Fixing the issue in *_Types.castIfNecessary_* directly seems to be not a
> good idea.
> On one hand, it is not convenient to call _SqlFunctions_ in linq4j. One the
> other hand, it will brings duplicate with _*RexToLixTranslator.cast*_.
> However, due to some unique logic in _*Types.castIfNecessary*_, we cannot
> replace it as _*RexToLixTranslator.cast*_ neither.
> Therefore, it is a good idea to integrate implementations into
> RexToLixTranslator.cast.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3416) SQL Dialects "DEFAULT"s should be more extensible
[ https://issues.apache.org/jira/browse/CALCITE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952466#comment-16952466 ] Julian Hyde commented on CALCITE-3416: -- I agree. And it would also be very nice if we don't have connection leaks. And I can't think of a design that does both. > SQL Dialects "DEFAULT"s should be more extensible > - > > Key: CALCITE-3416 > URL: https://issues.apache.org/jira/browse/CALCITE-3416 > Project: Calcite > Issue Type: Improvement >Reporter: Steven Talbot >Priority: Minor > > The behavior of SQLDialect is partly governed by the methods defined on the > given dialect subclass and partly governed by options passed in in a Context > object. So every dialect subclass exposes a "DEFAULT" instance that has been > initialized with the correct Context. > However, if you then wish to extend the dialect for one reason or another, > you must create a new instance to extend, or of course create a whole new > subclass. In either case, you lose the options from the Context passed into > the default, which governs important behavior of the dialect. You can > copy-paste the relevant Context out of the Calcite code, but then you lose > future improvements or fixes that might land in mainline Calcite. > It would be nice if each dialect exposed the DEFAULT_CONTEXT that it passed > into its DEFAULT instance as a public final member. Then, when extending the > dialect, you simply initialize your extension with the DEFAULT_CONTEXT, and > if any customization needs to happens on the Context options that's easy to > do with the Context's API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3412) Response Error for FLOOR TIMESTAMP TO WEEK
[
https://issues.apache.org/jira/browse/CALCITE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952463#comment-16952463
]
Julian Hyde commented on CALCITE-3412:
--
It makes sense to also implement {{DAYOFWEEK(DATE)}}. In {{SqlFunctions}}, add
a function {{int dayOfWeek(DataContext)}}.
How do we know the first day of the week? It turns out that we have a
{{TimeZone}} and a {{Locale}} in our {{DataContext}} (based on connection
properties). With these, we can do {{Calendar.getInstance(timeZone,
locale).getFirstDayOfWeek()}}.
The implementation of {{FLOOR(... TO WEEK)}} should call {{dayOfWeek(root)}}.
> Response Error for FLOOR TIMESTAMP TO WEEK
> ---
>
> Key: CALCITE-3412
> URL: https://issues.apache.org/jira/browse/CALCITE-3412
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: mac,linux
>Reporter: huaicui
>Priority: Major
> Attachments: image-2019-10-15-13-33-34-896.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Floor timestamp to week exist error:
> The start day of the week is not Sunday or Monday, calcite use Thursday to
> split a week.
> Example:
> sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
> Response:
> 2017-01-26 00:00:00.0
>
> 2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
> the first day that we expect.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952456#comment-16952456 ] hailin.huang edited comment on CALCITE-1075 at 10/16/19 2:40 AM: - [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() to observer the dataFun function. * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrun type of java.sql.Date, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function return java.sql.date, however I can't use getDate() when use jdbc Driver to process it. why the return type of user defined fucnion is different from the actual return type? was (Author: aahi): [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() to observer the dataFun function. * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrun type of java.sql.Date, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function return java.sql.date, however I can only use getLong() when use jdbc Driver to process it. why the return type of user defined fucnion is different from the actual return type? > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at
[jira] [Comment Edited] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952456#comment-16952456 ] hailin.huang edited comment on CALCITE-1075 at 10/16/19 2:39 AM: - [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() to observer the dataFun function. * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrun type of java.sql.Date, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function return java.sql.date, however I can only use getLong() when use jdbc Driver to process it. why the return type of user defined fucnion is different from the actual return type? was (Author: aahi): [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() to observer the dataFun function. * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrun type of java.sql.Date, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function reture java.sql.date, however I can only use getLong when use jdbc Driver to process it. why the return type of user defined fucnion is different from the accutual return type? > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at
[jira] [Comment Edited] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952456#comment-16952456 ] hailin.huang edited comment on CALCITE-1075 at 10/16/19 2:38 AM: - [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() to observer the dataFun function. * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrun type of java.sql.Date, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function reture java.sql.date, however I can only use getLong when use jdbc Driver to process it. why the return type of user defined fucnion is different from the accutual return type? was (Author: aahi): [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() to observer the dataFun function. * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrue type, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function reture java.sql.date, however I can only use getLong when use jdbc Driver to process it. why the return type of user defined fucnion is different from the accutual return type? > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at
[jira] [Comment Edited] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952456#comment-16952456 ] hailin.huang edited comment on CALCITE-1075 at 10/16/19 2:37 AM: - [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() to observer the dataFun function. * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrue type, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function reture java.sql.date, however I can only use getLong when use jdbc Driver to process it. why the return type of user defined fucnion is different from the accutual return type? was (Author: aahi): [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() to observer the dataFun. * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrue type, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function reture java.sql.date, however I can only use getLong when use jdbc Driver to process it. why the return type of user defined fucnion is different from the accutual return type? > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at testPs.TestPs.main(TestPs.java:150) > > 3. UDFs with
[jira] [Comment Edited] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952456#comment-16952456 ] hailin.huang edited comment on CALCITE-1075 at 10/16/19 2:37 AM: - [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() to observer the dataFun. * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrue type, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function reture java.sql.date, however I can only use getLong when use jdbc Driver to process it. why the return type of user defined fucnion is different from the accutual return type? was (Author: aahi): [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrue type, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function reture java.sql.date, however I can only use getLong when use jdbc Driver to process it. why the return type of user defined fucnion is different from the accutual return type? > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at testPs.TestPs.main(TestPs.java:150) > > 3. UDFs with same name and different arg types
[jira] [Commented] (CALCITE-3416) SQL Dialects "DEFAULT"s should be more extensible
[
https://issues.apache.org/jira/browse/CALCITE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952457#comment-16952457
]
Danny Chen commented on CALCITE-3416:
-
Well, i think [~swtalbot]'s request is that how to config or fine tweak a
sub-class SqlDialect, for example, how we can change the unquotedCasing for
BigQuerySqlDialect, this may be the code for current codes:
{code:java}
SqlDialect dialect = new BigQuerySqlDialect(
EMPTY_CONTEXT
.withDatabaseProduct(SqlDialect.DatabaseProduct.BIG_QUERY)
.withLiteralQuoteString("'")
.withLiteralEscapedQuoteString("\\'")
.withIdentifierQuoteString("`")
.withNullCollation(NullCollation.LOW)
.withUnquotedCasing(Casing.UPPER_CASE) // what we have changed
.withQuotedCasing(Casing.UNCHANGED)
.withCaseSensitive(false));
{code}
It would be nice if we do not copy these redundant codes.
> SQL Dialects "DEFAULT"s should be more extensible
> -
>
> Key: CALCITE-3416
> URL: https://issues.apache.org/jira/browse/CALCITE-3416
> Project: Calcite
> Issue Type: Improvement
>Reporter: Steven Talbot
>Priority: Minor
>
> The behavior of SQLDialect is partly governed by the methods defined on the
> given dialect subclass and partly governed by options passed in in a Context
> object. So every dialect subclass exposes a "DEFAULT" instance that has been
> initialized with the correct Context.
> However, if you then wish to extend the dialect for one reason or another,
> you must create a new instance to extend, or of course create a whole new
> subclass. In either case, you lose the options from the Context passed into
> the default, which governs important behavior of the dialect. You can
> copy-paste the relevant Context out of the Calcite code, but then you lose
> future improvements or fixes that might land in mainline Calcite.
> It would be nice if each dialect exposed the DEFAULT_CONTEXT that it passed
> into its DEFAULT instance as a public final member. Then, when extending the
> dialect, you simply initialize your extension with the DEFAULT_CONTEXT, and
> if any customization needs to happens on the Context options that's easy to
> do with the Context's API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952456#comment-16952456 ] hailin.huang commented on CALCITE-1075: --- [~julianhyde] Thanks for your quick response! Accutualy I had run the test case class UdfTest .testReturnDate, which I think test user-defined date functions in Small.AllTypeFunctions.dateFun. and modified CaciteAssert.checkResultValue() * the original code is "resultSet.getString(1)" , it run successfully. * I know the dateFun function will retrue type, so I chande the code to " resultSet.getDate(1)", it throw SqlDataException:cannot covert to Date. * I chand the code to " resultSet.getLong(1)", it run successfully. It make me confused, my self-defined function reture java.sql.date, however I can only use getLong when use jdbc Driver to process it. why the return type of user defined fucnion is different from the accutual return type? > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at testPs.TestPs.main(TestPs.java:150) > > 3. UDFs with same name and different arg types > UDF： DATE_TRUNC（Timestamp D, String x） returns a timestamp value > DATE_TRUNC(Date D, String x) returns a date value > > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > Error stack： > Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, > column 11 to line 1, column 32: Cannot apply 'DATE_TRUNC' to arguments of > type 'DATE_TRUNC(, )'. Supported form(s): > 'DATE_TRUNC(, )' > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at >
[jira] [Commented] (CALCITE-3415) Cannot parse REGEXP_SUBSTR in BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952442#comment-16952442
]
Danny Chen commented on CALCITE-3415:
-
Thanks [~pranay.parmar] for reporting this, i checked that there indeed don't
have a REGEXP_SUBSTR function in Calcite now, i found that Oracle has such
function as you described, maybe we can add one for the Oracle dialect. You can
add one in SqlLibraryOperators[2]
[1] https://docs.oracle.com/cd/B12037_01/server.101/b10759/functions116.htm
[2]
https://github.com/apache/calcite/blob/3cbbafa941128dc5097c2a26711f5751f764e12d/core/src/main/java/org/apache/calcite/sql/fun/SqlLibraryOperators.java#L173
> Cannot parse REGEXP_SUBSTR in BigQuery
> --
>
> Key: CALCITE-3415
> URL: https://issues.apache.org/jira/browse/CALCITE-3415
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Pranay Parmar
>Priority: Minor
> Fix For: 1.22.0
>
>
> REGEXP_SUBSTR error :
> {code:java}
> No match found for function signature REGEXP_SUBSTR(, ,
> [, , ]){code}
>
> Example query:
> {code:sql}
> SELECT REGEXP_SUBSTR('chocolate Chip cookies', 'c+.{2}', 1, product_id, 'i')
> FROM public.account{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-1862) StackOverflowException in RelMdUtil.estimateFilteredRows
[
https://issues.apache.org/jira/browse/CALCITE-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952440#comment-16952440
]
Haisheng Yuan commented on CALCITE-1862:
Now with latest master, the stack overflow can't be reproduced anymore. But the
result are nulls, instead of empty values.
> StackOverflowException in RelMdUtil.estimateFilteredRows
>
>
> Key: CALCITE-1862
> URL: https://issues.apache.org/jira/browse/CALCITE-1862
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> The query
> {code}select *
> from (
> select *
> from (
> select cast(null as integer) as d
> from "scott".emp)
> where d is null and d is null)
> where d is null;{code}
> gives
> {noformat}
> java.lang.StackOverflowError
> > at
> > org.apache.calcite.adapter.clone.ArrayTable.getStatistic(ArrayTable.java:76)
> > at
> > org.apache.calcite.prepare.RelOptTableImpl.getRowCount(RelOptTableImpl.java:224)
> > at
> > org.apache.calcite.rel.core.TableScan.estimateRowCount(TableScan.java:75)
> > at
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:206)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at
> > org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718)
> > at
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:123)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at
> > org.apache.calcite.rel.metadata.RelMdRowCount.getRowCount(RelMdRowCount.java:71)
> > at GeneratedMetadataHandler_RowCount.getRowCount_$(Unknown Source)
> > at GeneratedMetadataHandler_RowCount.getRowCount(Unknown Source)
> > at
> > org.apache.calcite.rel.metadata.RelMetadataQuery.getRowCount(RelMetadataQuery.java:236)
> > at
> > org.apache.calcite.rel.metadata.RelMdUtil.estimateFilteredRows(RelMdUtil.java:718){noformat}
> For a test case, add the query to misc.iq and run QuidemTest.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3412) Response Error for FLOOR TIMESTAMP TO WEEK
[
https://issues.apache.org/jira/browse/CALCITE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951750#comment-16951750
]
huaicui edited comment on CALCITE-3412 at 10/16/19 12:56 AM:
-
[~danny0405] We have provided a date and want to get the date of the first day
of the week，but the result is the date of this Thursday.
Mysql Example:
If the week starts on Sunday do this:
select DATE_ADD(now(), INTERVAL(1-DAYOFWEEK(now())) DAY)
If the week starts on Monday do this:
select DATE_ADD(now(), INTERVAL(-WEEKDAY(now())) DAY);
We use this sql of the calcite to get what we want:
select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK)
But the result is the date of this Thursday.
Can you give suggestion to fix that?
was (Author: kofiori):
We have provided a date and want to get the date of the first day of the
week，but the result is the date of this Thursday.
Mysql Example:
If the week starts on Sunday do this:
select DATE_ADD(now(), INTERVAL(1-DAYOFWEEK(now())) DAY)
If the week starts on Monday do this:
select DATE_ADD(now(), INTERVAL(-WEEKDAY(now())) DAY);
We use this sql of the calcite to get what we want:
select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK)
But the result is the date of this Thursday.
Can you give suggestion to fix that?
> Response Error for FLOOR TIMESTAMP TO WEEK
> ---
>
> Key: CALCITE-3412
> URL: https://issues.apache.org/jira/browse/CALCITE-3412
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: mac,linux
>Reporter: huaicui
>Priority: Major
> Attachments: image-2019-10-15-13-33-34-896.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Floor timestamp to week exist error:
> The start day of the week is not Sunday or Monday, calcite use Thursday to
> split a week.
> Example:
> sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
> Response:
> 2017-01-26 00:00:00.0
>
> 2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
> the first day that we expect.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952397#comment-16952397 ] Julian Hyde commented on CALCITE-1075: -- It's probably fixed. Can you try running the test cases? Calling getObject() on a TIMESTAMP or DATE column is not a great idea. You may not get timezone conversion. > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at testPs.TestPs.main(TestPs.java:150) > > 3. UDFs with same name and different arg types > UDF： DATE_TRUNC（Timestamp D, String x） returns a timestamp value > DATE_TRUNC(Date D, String x) returns a date value > > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > Error stack： > Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, > column 11 to line 1, column 32: Cannot apply 'DATE_TRUNC' to arguments of > type 'DATE_TRUNC(, )'. Supported form(s): > 'DATE_TRUNC(, )' > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:715) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:703) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:3932) > at > org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:275) > at > org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:92) > at >
[jira] [Commented] (CALCITE-3318) Preserving CAST of STRING operands in comparison operator
[
https://issues.apache.org/jira/browse/CALCITE-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952394#comment-16952394
]
Julian Hyde commented on CALCITE-3318:
--
Minor quibble: string is not a SQL type, so why is STRING capitalized in the
summary? Also, the summary does not make it clear what you regard as the
desired behavior.
> Preserving CAST of STRING operands in comparison operator
> -
>
> Key: CALCITE-3318
> URL: https://issues.apache.org/jira/browse/CALCITE-3318
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: Soma Mondal
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> We have a REL which has this information
> select * from employee where employee_id = cast('12' as float);
> but Calcite removes the CAST from the STRING literal('12' in our case).
> select * from employee where employee_id = '12';
> There are dialects which needs explicit casting in the above case and we need
> to maintain the CAST in our dialect.
> Calcite removes the cast in SqlImplementor's stripCastFromString() method.
> I'm thinking of having the dialect intercept this and decide whether or not
> to remove the cast.
>
> I have created a PR [https://github.com/apache/calcite/pull/1437]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3399) RelFieldTrimmer trim fields for UNION, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL
[
https://issues.apache.org/jira/browse/CALCITE-3399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952392#comment-16952392
]
Julian Hyde commented on CALCITE-3399:
--
The current title "RelFieldTrimmer trim fields for UNION, INTERSECT, INTERSECT
ALL, EXCEPT, EXCEPT ALL" doesn't say whether trimming fields is desired or
undesired behavior. How about "Field-pruning for set operators (except UNION
ALL) changes query semantics"?
> RelFieldTrimmer trim fields for UNION, INTERSECT, INTERSECT ALL, EXCEPT,
> EXCEPT ALL
> ---
>
> Key: CALCITE-3399
> URL: https://issues.apache.org/jira/browse/CALCITE-3399
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: jin xing
>Assignee: jin xing
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> *RelFieldTrimmer#trimFields* provides functionality to trim fields for
> *UNION, UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL;*
> But *UNION ALL, INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL* works by
> checking duplication. Column pruning on inputs of *SetOp* might lead to
> different semantics.
>
> Take below example for illustration
> {code:java}
> emp0:
> name, deptno
> "A", 0
> "B", 1
> emp1:
> name, deptno
> "C", 0
> "D", 2
> select deptno from
> (select name, deptno from emp0
> intersect
> select name, deptno from emp1)
> {code}
> Run above Sql on emp0 and emp1, result is not empty if trim fields on inputs
> of INTERSECT, but result is empty if DO NOT trim fields on inputs of INTERSECT
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3403) WindowReduceExpressionsRule does not reuse RelMetadataQuery
[
https://issues.apache.org/jira/browse/CALCITE-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952384#comment-16952384
]
Julian Hyde commented on CALCITE-3403:
--
The change can stand. I see now why {{RelOptCluster.getMetadataQuery()}} is
more efficient than {{RelMetadataQuery.instance()}}. And it's harmless to call
it from deprecated methods.
> WindowReduceExpressionsRule does not reuse RelMetadataQuery
> ---
>
> Key: CALCITE-3403
> URL: https://issues.apache.org/jira/browse/CALCITE-3403
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Assignee: jin xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> It creates a new RelMetadataQuery instance, which is a fresh RelMetadataQuery
> without any data cache. We should get RelMetadataQuery from RelOptRuleCall to
> reuse cache as much as possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3403) WindowReduceExpressionsRule does not reuse RelMetadataQuery
[
https://issues.apache.org/jira/browse/CALCITE-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952375#comment-16952375
]
Haisheng Yuan commented on CALCITE-3403:
How about I remove the change for deprecated methods?
For non-deprecated methods, do you still prefer using
{{RelMetadataQuery.instance()}}?
> WindowReduceExpressionsRule does not reuse RelMetadataQuery
> ---
>
> Key: CALCITE-3403
> URL: https://issues.apache.org/jira/browse/CALCITE-3403
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Assignee: jin xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> It creates a new RelMetadataQuery instance, which is a fresh RelMetadataQuery
> without any data cache. We should get RelMetadataQuery from RelOptRuleCall to
> reuse cache as much as possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3402) Allow RANGE with compoud ORDER BY clause
[
https://issues.apache.org/jira/browse/CALCITE-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952372#comment-16952372
]
Julian Hyde commented on CALCITE-3402:
--
Did you try changing {{RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED
FOLLOWING}} to {{ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING}}?
That should work.
If you use {{RANGE}} with a composite {{ORDER BY}}, does PostgreSQL apply the
range to just the first key? The documentation you referenced does not say.
> Allow RANGE with compoud ORDER BY clause
>
>
> Key: CALCITE-3402
> URL: https://issues.apache.org/jira/browse/CALCITE-3402
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.18.0, 1.19.0
>Reporter: benj
>Priority: Major
>
> It will be very useful to have the capacity to use compound ORDER BY clause
> with RANGE
> {code:sql}
> apache drill (dfs.tmp)> SELECT a
> , last_value(c) OVER(PARTITION BY a ORDER BY c, b DESC RANGE BETWEEN
> UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING)
> FROM (SELECT 1 a, 'b' b, 3 c
> UNION SELECT 2, 'c', 4
> UNION SELECT 1, 'c', 4
> /* UNION ... */
> ) x;
> Error: VALIDATION ERROR: From line 2, column 56 to line 2, column 60: RANGE
> clause cannot be used with compound ORDER BY clause
> {code}
> I know it's possible (for last_value) to rewrite with first_value with an
> reverse ORDER BY and without RANGE to obtain correct result.
> But it will become sometimes less readable and request write from other SGBDR
> will not be compatible and should be rewrite, and for some other function
> than last_value, the problem will not be solved like that.
> compound ORDER BY clause with RANGE is possible with some SGBDR like
> Postgres:
> [https://www.postgresql.org/docs/9.3/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3403) WindowReduceExpressionsRule does not reuse RelMetadataQuery
[
https://issues.apache.org/jira/browse/CALCITE-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952341#comment-16952341
]
Julian Hyde commented on CALCITE-3403:
--
Sorry, I have to grumble about this change.
Most of the changes in this PR are in deprecated methods, and you changed it to
call a method that is semi-deprecated ("This method might be changed or moved
in future.").
> WindowReduceExpressionsRule does not reuse RelMetadataQuery
> ---
>
> Key: CALCITE-3403
> URL: https://issues.apache.org/jira/browse/CALCITE-3403
> Project: Calcite
> Issue Type: Improvement
>Reporter: Haisheng Yuan
>Assignee: jin xing
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> It creates a new RelMetadataQuery instance, which is a fresh RelMetadataQuery
> without any data cache. We should get RelMetadataQuery from RelOptRuleCall to
> reuse cache as much as possible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3418) Grouped Window Function TUMBLE should return "$TUMBLE" as its operator name
[ https://issues.apache.org/jira/browse/CALCITE-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3418: Labels: pull-request-available (was: ) > Grouped Window Function TUMBLE should return "$TUMBLE" as its operator name > --- > > Key: CALCITE-3418 > URL: https://issues.apache.org/jira/browse/CALCITE-3418 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > Labels: pull-request-available > > In CALCITE-3382, we renamed Grouped Window Function TUMBLE to "$TUMBLE" but > still decided to return "TUMBLE" as the operator name. It turns out, in > order to avoid operator overloading and continue working on CALCITE-3340, > TUMBLE should return "$TUMBLE" as its name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3418) Grouped Window Function TUMBLE should return "$TUMBLE" as its operator name
[ https://issues.apache.org/jira/browse/CALCITE-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-3418: -- Summary: Grouped Window Function TUMBLE should return "$TUMBLE" as its operator name (was: Grouped Window Function TUMBLE should return "$TUMBLE" as its name) > Grouped Window Function TUMBLE should return "$TUMBLE" as its operator name > --- > > Key: CALCITE-3418 > URL: https://issues.apache.org/jira/browse/CALCITE-3418 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > In CALCITE-3382, we renamed Grouped Window Function TUMBLE to "$TUMBLE" but > still decided to return "TUMBLE" as the operator name. It turns out, in > order to avoid operator overloading and continue working on CALCITE-3340, > TUMBLE should return "$TUMBLE" as its name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3417) The alias is invalid in RelBuilder#join(JoinRelType, RexNode)
[
https://issues.apache.org/jira/browse/CALCITE-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952308#comment-16952308
]
Julian Hyde commented on CALCITE-3417:
--
When referencing a field for a join, you have to tell RelBuilder how many
inputs there are going to be. Then it can get the offset of the field within
the row correct. That's why it refuses to see "t" - it is only looking at the
top entry of the stack, 'a', because it assumes that you are going to use 1
input.
I acknowledge that the error message is very unhelpful.
> The alias is invalid in RelBuilder#join(JoinRelType, RexNode)
> -
>
> Key: CALCITE-3417
> URL: https://issues.apache.org/jira/browse/CALCITE-3417
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0, 1.21.0
>Reporter: jamie12221
>Priority: Trivial
>
> bad code:
> {code}
> RelBuilder relBuilder = RelBuilder.create(config);
> RelNode table = relBuilder
> .scan("testdb","travelrecord")
> .as("t")
> .scan("testdb","address")
> .as("a")
> .join(JoinRelType.INNER, relBuilder.equals(relBuilder.field("t","id"),
> relBuilder.field("a","id")))
>
> .filter(relBuilder.and(relBuilder.equals(relBuilder.field(1,0,"id"),relBuilder.literal(1
> .project(relBuilder.field(1,0,"id"), relBuilder.field(1,0,"user_id"))
> .build();
> {code}
> occur exception:
> {noformat}
> java.lang.IllegalArgumentException: no aliased field found; fields are:
> [\{aliases=[address, a],fieldName=id}, \{aliases=[address,
> a],fieldName=addressname}]java.lang.IllegalArgumentException: no aliased
> field found; fields are: [\{aliases=[address, a],fieldName=id},
> \{aliases=[address, a],fieldName=addressname}] at
> org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:511) at
> org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:487)
> {noformat}
>
> but it is ok :
> {code}
> RelBuilder relBuilder = RelBuilder.create(config);
> RelNode table = relBuilder
> .scan("testdb","travelrecord")
> .as("t")
> .scan("testdb","address")
> .as("a")
> .join(JoinRelType.INNER,
> relBuilder.equals(relBuilder.field({color:#de350b}2{color},"t","id"),
> relBuilder.field(2,"a","id")))
>
> .filter(relBuilder.and(relBuilder.equals(relBuilder.field(1,0,"id"),relBuilder.literal(1
> .project(relBuilder.field(1,0,"id"), relBuilder.field(1,0,"user_id"))
> .build();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3418) Grouped Window Function TUMBLE should return "$TUMBLE" as its name
[ https://issues.apache.org/jira/browse/CALCITE-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-3418: -- Description: In CALCITE-3382, we renamed Grouped Window Function TUMBLE to "$TUMBLE" but still decided to return "TUMBLE" as the operator name. It turns out, in order to avoid operator overloading and continue working on CALCITE-3340, TUMBLE should return "$TUMBLE" as its name. was:In CALCITE-3382, we renamed Grouped Window Function TUMBLE to "$TUMBLE" but still decided to return "TUMBLE" > Grouped Window Function TUMBLE should return "$TUMBLE" as its name > -- > > Key: CALCITE-3418 > URL: https://issues.apache.org/jira/browse/CALCITE-3418 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > In CALCITE-3382, we renamed Grouped Window Function TUMBLE to "$TUMBLE" but > still decided to return "TUMBLE" as the operator name. It turns out, in > order to avoid operator overloading and continue working on CALCITE-3340, > TUMBLE should return "$TUMBLE" as its name. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3418) Grouped Window Function TUMBLE should return "$TUMBLE" as its name
[ https://issues.apache.org/jira/browse/CALCITE-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-3418: -- Summary: Grouped Window Function TUMBLE should return "$TUMBLE" as its name (was: Grouped Window Function "$TUMBLE" should return "$TUMBLE" as its name) > Grouped Window Function TUMBLE should return "$TUMBLE" as its name > -- > > Key: CALCITE-3418 > URL: https://issues.apache.org/jira/browse/CALCITE-3418 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > In CALCITE-3382, we renamed Grouped Window Function TUMBLE to "$TUMBLE" but > still decided to return "TUMBLE" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3418) Grouped Window Function "$TUMBLE" should return "$TUMBLE" as its name
[ https://issues.apache.org/jira/browse/CALCITE-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-3418: -- Description: In CALCITE-3382, we renamed Grouped Window Function TUMBLE to "$TUMBLE" but still decided to return "TUMBLE" > Grouped Window Function "$TUMBLE" should return "$TUMBLE" as its name > - > > Key: CALCITE-3418 > URL: https://issues.apache.org/jira/browse/CALCITE-3418 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > In CALCITE-3382, we renamed Grouped Window Function TUMBLE to "$TUMBLE" but > still decided to return "TUMBLE" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-3418) Grouped Window Function "$TUMBLE" should return "$TUMBLE" as its name
[ https://issues.apache.org/jira/browse/CALCITE-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang reassigned CALCITE-3418: - Assignee: Rui Wang > Grouped Window Function "$TUMBLE" should return "$TUMBLE" as its name > - > > Key: CALCITE-3418 > URL: https://issues.apache.org/jira/browse/CALCITE-3418 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3418) Grouped Window Function "$TUMBLE" should return "
Rui Wang created CALCITE-3418: - Summary: Grouped Window Function "$TUMBLE" should return " Key: CALCITE-3418 URL: https://issues.apache.org/jira/browse/CALCITE-3418 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3418) Grouped Window Function "$TUMBLE" should return "$TUMBLE" as its name
[ https://issues.apache.org/jira/browse/CALCITE-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-3418: -- Summary: Grouped Window Function "$TUMBLE" should return "$TUMBLE" as its name (was: Grouped Window Function "$TUMBLE" should return " ) > Grouped Window Function "$TUMBLE" should return "$TUMBLE" as its name > - > > Key: CALCITE-3418 > URL: https://issues.apache.org/jira/browse/CALCITE-3418 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3417) The alias is invalid in RelBuilder#join(JoinRelType, RexNode)
[
https://issues.apache.org/jira/browse/CALCITE-3417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3417:
-
Description:
bad code:
{code}
RelBuilder relBuilder = RelBuilder.create(config);
RelNode table = relBuilder
.scan("testdb","travelrecord")
.as("t")
.scan("testdb","address")
.as("a")
.join(JoinRelType.INNER, relBuilder.equals(relBuilder.field("t","id"),
relBuilder.field("a","id")))
.filter(relBuilder.and(relBuilder.equals(relBuilder.field(1,0,"id"),relBuilder.literal(1
.project(relBuilder.field(1,0,"id"), relBuilder.field(1,0,"user_id"))
.build();
{code}
occur exception:
{noformat}
java.lang.IllegalArgumentException: no aliased field found; fields are:
[\{aliases=[address, a],fieldName=id}, \{aliases=[address,
a],fieldName=addressname}]java.lang.IllegalArgumentException: no aliased field
found; fields are: [\{aliases=[address, a],fieldName=id}, \{aliases=[address,
a],fieldName=addressname}] at
org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:511) at
org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:487)
{noformat}
but it is ok :
{code}
RelBuilder relBuilder = RelBuilder.create(config);
RelNode table = relBuilder
.scan("testdb","travelrecord")
.as("t")
.scan("testdb","address")
.as("a")
.join(JoinRelType.INNER,
relBuilder.equals(relBuilder.field({color:#de350b}2{color},"t","id"),
relBuilder.field(2,"a","id")))
.filter(relBuilder.and(relBuilder.equals(relBuilder.field(1,0,"id"),relBuilder.literal(1
.project(relBuilder.field(1,0,"id"), relBuilder.field(1,0,"user_id"))
.build();
{code}
was:
bad code:
RelBuilder relBuilder = RelBuilder.create(config);
RelNode table = relBuilder
.scan("testdb","travelrecord")
.as("t")
.scan("testdb","address")
.as("a")
.join(JoinRelType.INNER, relBuilder.equals(relBuilder.field("t","id"),
relBuilder.field("a","id")))
.filter(relBuilder.and(relBuilder.equals(relBuilder.field(1,0,"id"),relBuilder.literal(1
.project(relBuilder.field(1,0,"id"), relBuilder.field(1,0,"user_id"))
.build();
occur exception:
java.lang.IllegalArgumentException: no aliased field found; fields are:
[\{aliases=[address, a],fieldName=id}, \{aliases=[address,
a],fieldName=addressname}]java.lang.IllegalArgumentException: no aliased field
found; fields are: [\{aliases=[address, a],fieldName=id}, \{aliases=[address,
a],fieldName=addressname}] at
org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:511) at
org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:487)
but it is ok :
RelBuilder relBuilder = RelBuilder.create(config);
RelNode table = relBuilder
.scan("testdb","travelrecord")
.as("t")
.scan("testdb","address")
.as("a")
.join(JoinRelType.INNER,
relBuilder.equals(relBuilder.field({color:#de350b}2{color},"t","id"),
relBuilder.field(2,"a","id")))
.filter(relBuilder.and(relBuilder.equals(relBuilder.field(1,0,"id"),relBuilder.literal(1
.project(relBuilder.field(1,0,"id"), relBuilder.field(1,0,"user_id"))
.build();
> The alias is invalid in RelBuilder#join(JoinRelType, RexNode)
> -
>
> Key: CALCITE-3417
> URL: https://issues.apache.org/jira/browse/CALCITE-3417
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0, 1.21.0
>Reporter: jamie12221
>Priority: Trivial
>
> bad code:
> {code}
> RelBuilder relBuilder = RelBuilder.create(config);
> RelNode table = relBuilder
> .scan("testdb","travelrecord")
> .as("t")
> .scan("testdb","address")
> .as("a")
> .join(JoinRelType.INNER, relBuilder.equals(relBuilder.field("t","id"),
> relBuilder.field("a","id")))
>
> .filter(relBuilder.and(relBuilder.equals(relBuilder.field(1,0,"id"),relBuilder.literal(1
> .project(relBuilder.field(1,0,"id"), relBuilder.field(1,0,"user_id"))
> .build();
> {code}
> occur exception:
> {noformat}
> java.lang.IllegalArgumentException: no aliased field found; fields are:
> [\{aliases=[address, a],fieldName=id}, \{aliases=[address,
> a],fieldName=addressname}]java.lang.IllegalArgumentException: no aliased
> field found; fields are: [\{aliases=[address, a],fieldName=id},
> \{aliases=[address, a],fieldName=addressname}] at
> org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:511) at
> org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:487)
> {noformat}
>
> but it is ok :
> {code}
> RelBuilder relBuilder = RelBuilder.create(config);
> RelNode table = relBuilder
> .scan("testdb","travelrecord")
> .as("t")
> .scan("testdb","address")
> .as("a")
> .join(JoinRelType.INNER,
> relBuilder.equals(relBuilder.field({color:#de350b}2{color},"t","id"),
> relBuilder.field(2,"a","id")))
>
> .filter(relBuilder.and(relBuilder.equals(relBuilder.field(1,0,"id"),relBuilder.literal(1
> .project(relBuilder.field(1,0,"id"),
[jira] [Commented] (CALCITE-2018) Queries failed with AssertionError: rel has lower cost than best cost of subset
[
https://issues.apache.org/jira/browse/CALCITE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952297#comment-16952297
]
Xiening Dai commented on CALCITE-2018:
--
I pushed an update to https://github.com/xndai/calcite/tree/2018 please take a
look.
> Queries failed with AssertionError: rel has lower cost than best cost of
> subset
> ---
>
> Key: CALCITE-2018
> URL: https://issues.apache.org/jira/browse/CALCITE-2018
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.0
>Reporter: Vova Vysotskyi
>Assignee: Danny Chen
>Priority: Critical
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Problem description*
> When rootLogger level is DEBUG, unit tests
> * MaterializationTest.testMaterializationSubstitution2
> * MaterializationTest.testJoinMaterializationUKFK8
> * MaterializationTest.testJoinMaterializationUKFK6
> * JdbcTest.testWhereNot
> unit tests are failed with error AssertionError: rel has lower cost than best
> cost of subset.
> Full stack trace for test
> {{MaterializationTest.testMaterializationSubstitution2}}:
> {noformat}
> java.lang.AssertionError: rel
> [rel#245:EnumerableUnion.ENUMERABLE.[](input#0=rel#246:Subset#5.ENUMERABLE.[],input#1=rel#239:Subset#6.ENUMERABLE.[0],all=true)]
> has lower cost {14.0 rows, 19.0 cpu, 0.0 io} than best cost {15.0 rows, 20.0
> cpu, 0.0 io} of subset [rel#243:Subset#7.ENUMERABLE.[]]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.validate(VolcanoPlanner.java:906)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:866)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:101)
> at
> org.apache.calcite.rel.AbstractRelNode.onRegister(AbstractRelNode.java:336)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1495)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:863)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.FilterProjectTransposeRule.onMatch(FilterProjectTransposeRule.java:143)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:187)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at org.apache.calcite.schema.Schemas.prepare(Schemas.java:346)
> at
> org.apache.calcite.materialize.MaterializationService$DefaultTableFactory.createTable(MaterializationService.java:374)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:137)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:99)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable$MaterializedViewTableMacro.(MaterializedViewTable.java:110)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable$MaterializedViewTableMacro.(MaterializedViewTable.java:100)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable.create(MaterializedViewTable.java:81)
> at org.apache.calcite.model.ModelHandler.visit(ModelHandler.java:364)
> at
> org.apache.calcite.model.JsonMaterialization.accept(JsonMaterialization.java:42)
> at org.apache.calcite.model.JsonSchema.visitChildren(JsonSchema.java:98)
> at
> org.apache.calcite.model.JsonMapSchema.visitChildren(JsonMapSchema.java:48)
> at
> org.apache.calcite.model.ModelHandler.populateSchema(ModelHandler.java:257)
[jira] [Resolved] (CALCITE-3403) WindowReduceExpressionsRule does not reuse RelMetadataQuery
[ https://issues.apache.org/jira/browse/CALCITE-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haisheng Yuan resolved CALCITE-3403. Fix Version/s: 1.22.0 Resolution: Fixed Fixed in https://github.com/apache/calcite/commit/3cbbafa941128dc5097c2a26711f5751f764e12d. > WindowReduceExpressionsRule does not reuse RelMetadataQuery > --- > > Key: CALCITE-3403 > URL: https://issues.apache.org/jira/browse/CALCITE-3403 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: jin xing >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > It creates a new RelMetadataQuery instance, which is a fresh RelMetadataQuery > without any data cache. We should get RelMetadataQuery from RelOptRuleCall to > reuse cache as much as possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-2018) Queries failed with AssertionError: rel has lower cost than best cost of subset
[
https://issues.apache.org/jira/browse/CALCITE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952268#comment-16952268
]
Xiening Dai commented on CALCITE-2018:
--
I can disable the validation in test. But I would also love to know what are
the extra things that are computed and affect the behavior. As I examine the
code path, the only stateful object updated in the validation pass is the
RelMetadataQuery.map. But since the RelMetadataQuery object used in validation
is a complete new object, that would not affect planner's behavior IMO.
The change with RelMetadataQuery is to make sure we have one single
RelMetadataQuery instance during the rule firing, so we can avoid the overhead
of instantiation of RelMetadataQuery and reuse the RelNode cost cache
(RelMetadataQuery.map). For this fix, I think the bigger change is to make sure
we clean RelNode cost cache entries when best rel is updated. In order to
remove a single cache entry, the cache map structure is also updated to include
RelNode as a key.
Regarding the minor point, this part was authored by [~volodymyr] But I can
made an update to swap the two arguments.
Thanks.
> Queries failed with AssertionError: rel has lower cost than best cost of
> subset
> ---
>
> Key: CALCITE-2018
> URL: https://issues.apache.org/jira/browse/CALCITE-2018
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.0
>Reporter: Vova Vysotskyi
>Assignee: Danny Chen
>Priority: Critical
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Problem description*
> When rootLogger level is DEBUG, unit tests
> * MaterializationTest.testMaterializationSubstitution2
> * MaterializationTest.testJoinMaterializationUKFK8
> * MaterializationTest.testJoinMaterializationUKFK6
> * JdbcTest.testWhereNot
> unit tests are failed with error AssertionError: rel has lower cost than best
> cost of subset.
> Full stack trace for test
> {{MaterializationTest.testMaterializationSubstitution2}}:
> {noformat}
> java.lang.AssertionError: rel
> [rel#245:EnumerableUnion.ENUMERABLE.[](input#0=rel#246:Subset#5.ENUMERABLE.[],input#1=rel#239:Subset#6.ENUMERABLE.[0],all=true)]
> has lower cost {14.0 rows, 19.0 cpu, 0.0 io} than best cost {15.0 rows, 20.0
> cpu, 0.0 io} of subset [rel#243:Subset#7.ENUMERABLE.[]]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.validate(VolcanoPlanner.java:906)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:866)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:101)
> at
> org.apache.calcite.rel.AbstractRelNode.onRegister(AbstractRelNode.java:336)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1495)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:863)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.FilterProjectTransposeRule.onMatch(FilterProjectTransposeRule.java:143)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:187)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at org.apache.calcite.schema.Schemas.prepare(Schemas.java:346)
> at
> org.apache.calcite.materialize.MaterializationService$DefaultTableFactory.createTable(MaterializationService.java:374)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:137)
> at
[jira] [Commented] (CALCITE-3415) Cannot parse REGEXP_SUBSTR in BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952231#comment-16952231
]
Rui Wang commented on CALCITE-3415:
---
I am not aware of REGEXP_SUBSTR exist in BigQuery (check [1]). The most closest
one is [2].
Could you elaborate a bit on which BigQuery function you intent to use?
[1]:
https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators
[2]:
https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#regexp_extract
> Cannot parse REGEXP_SUBSTR in BigQuery
> --
>
> Key: CALCITE-3415
> URL: https://issues.apache.org/jira/browse/CALCITE-3415
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Pranay Parmar
>Priority: Minor
> Fix For: 1.22.0
>
>
> REGEXP_SUBSTR error :
> {code:java}
> No match found for function signature REGEXP_SUBSTR(, ,
> [, , ]){code}
>
> Example query:
> {code:sql}
> SELECT REGEXP_SUBSTR('chocolate Chip cookies', 'c+.{2}', 1, product_id, 'i')
> FROM public.account{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3415) Cannot parse REGEXP_SUBSTR in BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952231#comment-16952231
]
Rui Wang edited comment on CALCITE-3415 at 10/15/19 7:10 PM:
-
I am not aware of REGEXP_SUBSTR exist in BigQuery (check [1]). The closest one
is [2].
Could you elaborate a bit on which BigQuery function you intent to use?
[1]:
https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators
[2]:
https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#regexp_extract
was (Author: amaliujia):
I am not aware of REGEXP_SUBSTR exist in BigQuery (check [1]). The most closest
one is [2].
Could you elaborate a bit on which BigQuery function you intent to use?
[1]:
https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators
[2]:
https://cloud.google.com/bigquery/docs/reference/standard-sql/functions-and-operators#regexp_extract
> Cannot parse REGEXP_SUBSTR in BigQuery
> --
>
> Key: CALCITE-3415
> URL: https://issues.apache.org/jira/browse/CALCITE-3415
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Pranay Parmar
>Priority: Minor
> Fix For: 1.22.0
>
>
> REGEXP_SUBSTR error :
> {code:java}
> No match found for function signature REGEXP_SUBSTR(, ,
> [, , ]){code}
>
> Example query:
> {code:sql}
> SELECT REGEXP_SUBSTR('chocolate Chip cookies', 'c+.{2}', 1, product_id, 'i')
> FROM public.account{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2018) Queries failed with AssertionError: rel has lower cost than best cost of subset
[
https://issues.apache.org/jira/browse/CALCITE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952223#comment-16952223
]
Julian Hyde commented on CALCITE-2018:
--
Minor point: you have changed the parameters of {{CalciteMaterializer}}
constructor from {{(CalcitePrepareImpl, CalcitePrepare.Context, CatalogReader,
CalciteSchema, RelOptPlanner, SqlRexConvertletTable)}} to
{{(CalcitePrepareImpl, CalcitePrepare.Context, CatalogReader, CalciteSchema,
RelOptPlanner,SqlRexConvertletTable, RelOptCluster)}}. Can you swap the last 2
arguments so that {{cluster}} is now in the same place that {{planner}} used to
be.
> Queries failed with AssertionError: rel has lower cost than best cost of
> subset
> ---
>
> Key: CALCITE-2018
> URL: https://issues.apache.org/jira/browse/CALCITE-2018
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.0
>Reporter: Vova Vysotskyi
>Assignee: Danny Chen
>Priority: Critical
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Problem description*
> When rootLogger level is DEBUG, unit tests
> * MaterializationTest.testMaterializationSubstitution2
> * MaterializationTest.testJoinMaterializationUKFK8
> * MaterializationTest.testJoinMaterializationUKFK6
> * JdbcTest.testWhereNot
> unit tests are failed with error AssertionError: rel has lower cost than best
> cost of subset.
> Full stack trace for test
> {{MaterializationTest.testMaterializationSubstitution2}}:
> {noformat}
> java.lang.AssertionError: rel
> [rel#245:EnumerableUnion.ENUMERABLE.[](input#0=rel#246:Subset#5.ENUMERABLE.[],input#1=rel#239:Subset#6.ENUMERABLE.[0],all=true)]
> has lower cost {14.0 rows, 19.0 cpu, 0.0 io} than best cost {15.0 rows, 20.0
> cpu, 0.0 io} of subset [rel#243:Subset#7.ENUMERABLE.[]]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.validate(VolcanoPlanner.java:906)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:866)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:101)
> at
> org.apache.calcite.rel.AbstractRelNode.onRegister(AbstractRelNode.java:336)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1495)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:863)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.FilterProjectTransposeRule.onMatch(FilterProjectTransposeRule.java:143)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:187)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at org.apache.calcite.schema.Schemas.prepare(Schemas.java:346)
> at
> org.apache.calcite.materialize.MaterializationService$DefaultTableFactory.createTable(MaterializationService.java:374)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:137)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:99)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable$MaterializedViewTableMacro.(MaterializedViewTable.java:110)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable$MaterializedViewTableMacro.(MaterializedViewTable.java:100)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable.create(MaterializedViewTable.java:81)
> at
[jira] [Commented] (CALCITE-2018) Queries failed with AssertionError: rel has lower cost than best cost of subset
[
https://issues.apache.org/jira/browse/CALCITE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952221#comment-16952221
]
Julian Hyde commented on CALCITE-2018:
--
With a dynamic programming algorithm, extra validation may cause extra things
to be computed, and therefore can change behavior. So let's disable the extra
validation.
As I said, you can have an additional test (as part of the long suite) that
runs with extra validation switched on. As long as we keep the test with
validation switched off.
Assertions enabled vs. disabled ({{-ea}} vs {{-da}}) is not the point. We
expect the test suite to pass with either.
Anyway.
The big change here is that we get {{RelMetadataQuery}} from the cluster,
rather than from the thread. Can you explain why that change was necessary? If
we had been more disciplined to close the {{RelMetadataQuery}} at the end of
preparation, would that have had the same effect?
Is {{RelMetadataQuery.instance()}} now obsolete? If not, what are the
circumstances when it is OK to call it?
> Queries failed with AssertionError: rel has lower cost than best cost of
> subset
> ---
>
> Key: CALCITE-2018
> URL: https://issues.apache.org/jira/browse/CALCITE-2018
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.0
>Reporter: Vova Vysotskyi
>Assignee: Danny Chen
>Priority: Critical
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Problem description*
> When rootLogger level is DEBUG, unit tests
> * MaterializationTest.testMaterializationSubstitution2
> * MaterializationTest.testJoinMaterializationUKFK8
> * MaterializationTest.testJoinMaterializationUKFK6
> * JdbcTest.testWhereNot
> unit tests are failed with error AssertionError: rel has lower cost than best
> cost of subset.
> Full stack trace for test
> {{MaterializationTest.testMaterializationSubstitution2}}:
> {noformat}
> java.lang.AssertionError: rel
> [rel#245:EnumerableUnion.ENUMERABLE.[](input#0=rel#246:Subset#5.ENUMERABLE.[],input#1=rel#239:Subset#6.ENUMERABLE.[0],all=true)]
> has lower cost {14.0 rows, 19.0 cpu, 0.0 io} than best cost {15.0 rows, 20.0
> cpu, 0.0 io} of subset [rel#243:Subset#7.ENUMERABLE.[]]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.validate(VolcanoPlanner.java:906)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:866)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:101)
> at
> org.apache.calcite.rel.AbstractRelNode.onRegister(AbstractRelNode.java:336)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1495)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:863)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.FilterProjectTransposeRule.onMatch(FilterProjectTransposeRule.java:143)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:187)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at org.apache.calcite.schema.Schemas.prepare(Schemas.java:346)
> at
> org.apache.calcite.materialize.MaterializationService$DefaultTableFactory.createTable(MaterializationService.java:374)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:137)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:99)
>
[jira] [Commented] (CALCITE-3382) Rename current TUMBLE to "$TUMBLE" and add TUMBLE to Parser
[ https://issues.apache.org/jira/browse/CALCITE-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952196#comment-16952196 ] Julian Hyde commented on CALCITE-3382: -- Option 2. Return "$TUMBLE" as the name. It is more straightforward. > Rename current TUMBLE to "$TUMBLE" and add TUMBLE to Parser > --- > > Key: CALCITE-3382 > URL: https://issues.apache.org/jira/browse/CALCITE-3382 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Per discussion in https://github.com/apache/calcite/pull/1457, we should add > TUMBLE to parser and rename it to "$TUMBLE". > "TUMBLE" as an operator name will be left for table-value function TUMBLE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3417) The alias is invalid in RelBuilder#join(JoinRelType, RexNode)
jamie12221 created CALCITE-3417:
---
Summary: The alias is invalid in RelBuilder#join(JoinRelType,
RexNode)
Key: CALCITE-3417
URL: https://issues.apache.org/jira/browse/CALCITE-3417
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.21.0, 1.20.0
Reporter: jamie12221
bad code:
RelBuilder relBuilder = RelBuilder.create(config);
RelNode table = relBuilder
.scan("testdb","travelrecord")
.as("t")
.scan("testdb","address")
.as("a")
.join(JoinRelType.INNER, relBuilder.equals(relBuilder.field("t","id"),
relBuilder.field("a","id")))
.filter(relBuilder.and(relBuilder.equals(relBuilder.field(1,0,"id"),relBuilder.literal(1
.project(relBuilder.field(1,0,"id"), relBuilder.field(1,0,"user_id"))
.build();
occur exception:
java.lang.IllegalArgumentException: no aliased field found; fields are:
[\{aliases=[address, a],fieldName=id}, \{aliases=[address,
a],fieldName=addressname}]java.lang.IllegalArgumentException: no aliased field
found; fields are: [\{aliases=[address, a],fieldName=id}, \{aliases=[address,
a],fieldName=addressname}] at
org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:511) at
org.apache.calcite.tools.RelBuilder.field(RelBuilder.java:487)
but it is ok :
RelBuilder relBuilder = RelBuilder.create(config);
RelNode table = relBuilder
.scan("testdb","travelrecord")
.as("t")
.scan("testdb","address")
.as("a")
.join(JoinRelType.INNER,
relBuilder.equals(relBuilder.field({color:#de350b}2{color},"t","id"),
relBuilder.field(2,"a","id")))
.filter(relBuilder.and(relBuilder.equals(relBuilder.field(1,0,"id"),relBuilder.literal(1
.project(relBuilder.field(1,0,"id"), relBuilder.field(1,0,"user_id"))
.build();
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3412) Response Error for FLOOR TIMESTAMP TO WEEK
[
https://issues.apache.org/jira/browse/CALCITE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952187#comment-16952187
]
Julian Hyde commented on CALCITE-3412:
--
[~danny0405] I don't know how this function is supposed to know what is the
start day of the week. Maybe we should not allow 'FLOOR(... TO WEEK)'. Do any
databases support it? If so, how do they know which is the first day of the
week?
> Response Error for FLOOR TIMESTAMP TO WEEK
> ---
>
> Key: CALCITE-3412
> URL: https://issues.apache.org/jira/browse/CALCITE-3412
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: mac,linux
>Reporter: huaicui
>Priority: Major
> Attachments: image-2019-10-15-13-33-34-896.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Floor timestamp to week exist error:
> The start day of the week is not Sunday or Monday, calcite use Thursday to
> split a week.
> Example:
> sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
> Response:
> 2017-01-26 00:00:00.0
>
> 2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
> the first day that we expect.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3407) Implement Minus and Intersect relational operators in the interpreter
[
https://issues.apache.org/jira/browse/CALCITE-3407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3407:
-
Summary: Implement Minus and Intersect relational operators in the
interpreter (was: Add support for interpretering minus/intersect relational
set operators)
> Implement Minus and Intersect relational operators in the interpreter
> -
>
> Key: CALCITE-3407
> URL: https://issues.apache.org/jira/browse/CALCITE-3407
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently, for SetOp, only `union` is supported by Interpreter
> add the test cases in InterpreterTest, and run, they will fail by throwing
> exception
> {code:java}
> @Test public void testInterpretIntersect() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (1, 'a'), (1, 'a'), (2, 'b'), (3, 'c'))
> as t(x, y))\n"
> + "intersect\n"
> + "(select x, y from (values (1, 'a'), (2, 'c'), (4, 'x')) as t2(x,
> y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[1, a]");
> }
> @Test public void testInterpretIntersectAll() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (1, 'a'), (1, 'a'), (2, 'b'), (3, 'c'))
> as t(x, y))\n"
> + "intersect all\n"
> + "(select x, y from (values (1, 'a'), (2, 'c'), (4, 'x')) as t2(x,
> y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[1, a]", "[1, a]");
> }
> @Test public void testInterpretMinus() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (1, 'a'), (2, 'b'), (2, 'b'), (3, 'c'))
> as t(x, y))\n"
> + "except\n"
> + "(select x, y from (values (1, 'a'), (2, 'c'), (4, 'x')) as t2(x,
> y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[2, b]", "[3, c]");
> }
> @Test public void testInterpretMinusAll() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (1, 'a'), (2, 'b'), (2, 'b'), (3, 'c'))
> as t(x, y))\n"
> + "except all\n"
> + "(select x, y from (values (1, 'a'), (2, 'c'), (4, 'x')) as t2(x,
> y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[2, b]", "[2, b]", "[3, c]");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3408) Add support for Enumerable Intersect/Minus all
[
https://issues.apache.org/jira/browse/CALCITE-3408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952177#comment-16952177
]
Julian Hyde commented on CALCITE-3408:
--
Note that there is already {{IntersectToDistinctRule}}. I believe it would
successfully convert {{EnumerableIntersect(true)}} to
{{EnumerableIntersect(false)}}. That said, this is still a useful change.
Can you move the queries you added to {{JdbcTest}} to a new file
{{core/src/test/resources/sql/set-op.iq}}. {{JdbcTest.java}} is way too large
already.
In {{Linq4jTest.java}} please use {{assertThat}} rather than {{assertEquals}}.
(Yeah, I know there's a lot of {{assertEquals}} in that file. But we're moving
away from that.)
> Add support for Enumerable Intersect/Minus all
> --
>
> Key: CALCITE-3408
> URL: https://issues.apache.org/jira/browse/CALCITE-3408
> Project: Calcite
> Issue Type: Improvement
>Reporter: Wang Yanlin
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When running sql with calcite driver
> {code:java}
> final String sql = "select * from\n"
> + "(select x, y from (values (1, 'a'), (2, 'b'), (2, 'b'), (3, 'c'))
> as t(x, y))\n"
> + "except all\n"
> + "(select x, y from (values (1, 'a'), (2, 'c'), (4, 'x')) as t2(x,
> y))\n";
> {code}
> got
> {code:java}
> java.sql.SQLException: Error while executing SQL "explain plan for select *
> from
> (select x, y from (values (1, 'a'), (2, 'b'), (2, 'b'), (3, 'c')) as t(x, y))
> except all
> (select x, y from (values (1, 'a'), (2, 'c'), (4, 'x')) as t2(x, y))
> ": There are not enough rules to produce a node with desired properties:
> convention=ENUMERABLE, sort=[].
> Missing conversion is LogicalMinus[convention: NONE -> ENUMERABLE]
> There is 1 empty subset: rel#27:Subset#4.ENUMERABLE.[], the relevant part of
> the original plan is as follows
> 22:LogicalMinus(all=[true])
> 1:LogicalValues(subset=[rel#16:Subset#0.NONE.[]], tuples=[[{ 1, 'a' }, { 2,
> 'b' }, { 2, 'b' }, { 3, 'c' }]])
> 5:LogicalValues(subset=[rel#19:Subset#2.NONE.[]], tuples=[[{ 1, 'a' }, { 2,
> 'c' }, { 4, 'x' }]])
> Root: rel#27:Subset#4.ENUMERABLE.[]
> Original rel:
> LogicalMinus(all=[true]): rowcount = 3.0, cumulative cost = {17.0 rows, 19.0
> cpu, 0.0 io}, id = 14
> LogicalProject(X=[$0], Y=[$1]): rowcount = 4.0, cumulative cost = {8.0
> rows, 9.0 cpu, 0.0 io}, id = 9
> LogicalValues(tuples=[[{ 1, 'a' }, { 2, 'b' }, { 2, 'b' }, { 3, 'c' }]]):
> rowcount = 4.0, cumulative cost = {4.0 rows, 1.0 cpu, 0.0 io}, id = 1
> LogicalProject(X=[$0], Y=[$1]): rowcount = 3.0, cumulative cost = {6.0
> rows, 7.0 cpu, 0.0 io}, id = 12
> LogicalValues(tuples=[[{ 1, 'a' }, { 2, 'c' }, { 4, 'x' }]]): rowcount =
> 3.0, cumulative cost = {3.0 rows, 1.0 cpu, 0.0 io}, id = 5
> {code}
> Add these cases in JdbcTest to reproduce
> {code:java}
> @Test public void testExceptAll() {
> final String sql = "select * from\n"
> + "(select x, y from (values (1, 'a'), (2, 'b'), (2, 'b'), (3, 'c'))
> as t(x, y))\n"
> + "except all\n"
> + "(select x, y from (values (1, 'a'), (2, 'c'), (4, 'x')) as t2(x,
> y))\n";
> CalciteAssert.hr()
> .query(sql)
> .explainContains(""
> + "PLAN=EnumerableMinus(all=[true])")
> .returnsUnordered(
> "X=2, Y=b",
> "X=2, Y=b",
> "X=3, Y=c");
> }
> @Test public void testIntersectAll() {
> final String sql = "select * from\n"
> + "(select x, y from (values (1, 'a'), (1, 'a'), (2, 'b'), (3, 'c'))
> as t(x, y))\n"
> + "intersect all\n"
> + "(select x, y from (values (1, 'a'), (2, 'c'), (4, 'x')) as t2(x,
> y))\n";
> CalciteAssert.hr()
> .query(sql)
> .withHook(Hook.PLANNER, (Consumer) planner ->
> planner.removeRule(IntersectToDistinctRule.INSTANCE))
> .explainContains(""
> + "PLAN=EnumerableIntersect(all=[true])")
> .returnsUnordered(
> "X=1; Y=a",
> "X=1; Y=a");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3414) Unify Expression'type cast and conversion as a robust one
[
https://issues.apache.org/jira/browse/CALCITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952170#comment-16952170
]
Julian Hyde commented on CALCITE-3414:
--
I haven't looked at the PR, but let me state the strategy. Stuff in linq4j
should follow the rules of the Java language, whereas stuff in core follows the
rules of the SQL language (or our relational algebra), and the stuff layered on
top by the java runtime libraries (e.g. java.sql.Timestamp and
java.math.BigDecimal).
I think that {{Expressions.convert}} and {{Types.castIfNecessary}} follow that
policy. {{RexToLixTranslator.convert}} has a mixture - some stuff regarding
boxing/unboxing, and primitive to primitive (e.g. float to double), that should
be in linq4j, and some stuff such as converting java.sql.Timestamp to long and
BigDecimal to String that would remain in core.
> Unify Expression'type cast and conversion as a robust one
> -
>
> Key: CALCITE-3414
> URL: https://issues.apache.org/jira/browse/CALCITE-3414
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Attachments: RexToLixTranslator.png, TypeConversion.txt, Types.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current now, there are two functions in calcite that can be used to
> cast/convert Expression to a specific Type.
> *_Types.castIfNecessary_* and _*RexToLixTranslator.convert*_.
> We make a deep investigation on their implementations and demonstrate them as
> below.
> {color:#ff}
> !RexToLixTranslator.png!{color}
> {color:#ff}
> *RexToLixTranslator.convert*{color}
> !Types.png!
> {color:#ff}
> *Types.castIfNecessary*{color}
> It can be seen that:
> (1) They have a lot of overlaps;
> (2) *_RexToLixTranslator.cast_* can cover more cases with tools like
> _SqlFunctions_ and etc.
> (3) Both of them have limitations and may generate incorrect code, which is
> listed in attachment(TypeConversion.txt).
> Multiple choices usually bring confusion to developers and resulting to the
> misuse of them.
> For example, CALCITE-3245 exposes that Types.castIfNecessary cannot cast the
> Expression to BigDecimal.class.
> Fixing the issue in *_Types.castIfNecessary_* directly seems to be not a
> good idea.
> On one hand, it is not convenient to call _SqlFunctions_ in linq4j. One the
> other hand, it will brings duplicate with _*RexToLixTranslator.cast*_.
> However, due to some unique logic in _*Types.castIfNecessary*_, we cannot
> replace it as _*RexToLixTranslator.cast*_ neither.
> Therefore, it is a good idea to integrate implementations into
> RexToLixTranslator.cast.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3368) PLUS, MUNUS and TIMES should be unsafe when simplifying ‘expression IS NULL’
[
https://issues.apache.org/jira/browse/CALCITE-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952150#comment-16952150
]
Julian Hyde commented on CALCITE-3368:
--
I think the idea of a "safe expression" is over-complicated and unnecessary.
What you seem to want is a different + operator. It is different from the
current + operator - neither better nor worse - and it has different strongness
properties.
> PLUS, MUNUS and TIMES should be unsafe when 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
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> '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-3368) PLUS, MUNUS and TIMES should be unsafe when simplifying ‘expression IS NULL’
[
https://issues.apache.org/jira/browse/CALCITE-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952146#comment-16952146
]
Julian Hyde commented on CALCITE-3368:
--
The current behavior of Calcite is that it does not throw an exception.
{noformat}
./sqlline
sqlline version 1.8.0
sqlline> !connect jdbc:calcite: user pass
0: jdbc:calcite:> values 1073741824 + 1073741824;
++
| EXPR$0 |
++
| -2147483648 |
++
1 row selected (1.463 seconds)
{noformat}
Given the current behavior, it is correct to simplify {{(x + y) is null}} to
{{x is null or y is null}}.
If you would like a different behavior concerning integer overflow and
underflow, can you log another JIRA case?
> PLUS, MUNUS and TIMES should be unsafe when 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
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> '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-3416) SQL Dialects "DEFAULT"s should be more extensible
[
https://issues.apache.org/jira/browse/CALCITE-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952136#comment-16952136
]
Julian Hyde commented on CALCITE-3416:
--
Yes, but let's not do that by storing the {{Context}} inside the instance of
{{SqlDialect}}.
We have had problems in the past with people passing in a {{DatabaseMetaData}}
instance and creating connection leaks. So now the rule is that the constructor
takes what it needs from the {{Context}} and then forgets the {{Context}}.
> SQL Dialects "DEFAULT"s should be more extensible
> -
>
> Key: CALCITE-3416
> URL: https://issues.apache.org/jira/browse/CALCITE-3416
> Project: Calcite
> Issue Type: Improvement
>Reporter: Steven Talbot
>Priority: Minor
>
> The behavior of SQLDialect is partly governed by the methods defined on the
> given dialect subclass and partly governed by options passed in in a Context
> object. So every dialect subclass exposes a "DEFAULT" instance that has been
> initialized with the correct Context.
> However, if you then wish to extend the dialect for one reason or another,
> you must create a new instance to extend, or of course create a whole new
> subclass. In either case, you lose the options from the Context passed into
> the default, which governs important behavior of the dialect. You can
> copy-paste the relevant Context out of the Calcite code, but then you lose
> future improvements or fixes that might land in mainline Calcite.
> It would be nice if each dialect exposed the DEFAULT_CONTEXT that it passed
> into its DEFAULT instance as a public final member. Then, when extending the
> dialect, you simply initialize your extension with the DEFAULT_CONTEXT, and
> if any customization needs to happens on the Context options that's easy to
> do with the Context's API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3416) SQL Dialects "DEFAULT"s should be more extensible
Steven Talbot created CALCITE-3416: -- Summary: SQL Dialects "DEFAULT"s should be more extensible Key: CALCITE-3416 URL: https://issues.apache.org/jira/browse/CALCITE-3416 Project: Calcite Issue Type: Improvement Reporter: Steven Talbot The behavior of SQLDialect is partly governed by the methods defined on the given dialect subclass and partly governed by options passed in in a Context object. So every dialect subclass exposes a "DEFAULT" instance that has been initialized with the correct Context. However, if you then wish to extend the dialect for one reason or another, you must create a new instance to extend, or of course create a whole new subclass. In either case, you lose the options from the Context passed into the default, which governs important behavior of the dialect. You can copy-paste the relevant Context out of the Calcite code, but then you lose future improvements or fixes that might land in mainline Calcite. It would be nice if each dialect exposed the DEFAULT_CONTEXT that it passed into its DEFAULT instance as a public final member. Then, when extending the dialect, you simply initialize your extension with the DEFAULT_CONTEXT, and if any customization needs to happens on the Context options that's easy to do with the Context's API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3415) Cannot parse REGEXP_SUBSTR in BigQuery
Pranay Parmar created CALCITE-3415:
--
Summary: Cannot parse REGEXP_SUBSTR in BigQuery
Key: CALCITE-3415
URL: https://issues.apache.org/jira/browse/CALCITE-3415
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Pranay Parmar
Fix For: 1.22.0
REGEXP_SUBSTR error :
{code:java}
No match found for function signature REGEXP_SUBSTR(, ,
[, , ]){code}
Example query:
{code:sql}
SELECT REGEXP_SUBSTR('chocolate Chip cookies', 'c+.{2}', 1, product_id, 'i')
FROM public.account{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3413) AssertionError for interpertering union/intersect/minus with null value
[
https://issues.apache.org/jira/browse/CALCITE-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-3413.
Resolution: Fixed
> AssertionError for interpertering union/intersect/minus with null value
> ---
>
> Key: CALCITE-3413
> URL: https://issues.apache.org/jira/browse/CALCITE-3413
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> Add the following test case in *InterpreterTest*
> {code:java}
> @Test public void testInterpretUnionWithNullValue() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1))),\n"
> + "(cast(NULL as int), cast(NULL as varchar(1 as t(x, y))\n"
> + "union\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1 as t2(x, y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[null, null]");
> }
> @Test public void testInterpretUnionAllWithNullValue() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1))),\n"
> + "(cast(NULL as int), cast(NULL as varchar(1 as t(x, y))\n"
> + "union all\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1 as t2(x, y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[null, null]", "[null, null]", "[null, null]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.source(Interpreter.java:510)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.source(Nodes.java:46)
> at
> org.apache.calcite.interpreter.AbstractSingleNode.(AbstractSingleNode.java:33)
> at
> org.apache.calcite.interpreter.ProjectNode.(ProjectNode.java:31)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:60)
> 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.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:257)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:214)
> at
> org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:464)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:451)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:46)
> at
> org.apache.calcite.rel.AbstractRelNode.childrenAccept(AbstractRelNode.java:265)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:447)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:46)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:405)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:88)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretMinusWithNullValue(InterpreterTest.java:418)
> {code}
> The cause lies in the optimize of
> [Interpreter|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/interpreter/Interpreter.java#L85]
> before optimize, the relnode tree is as follows, no renode with same id exists
> {code:java}
> LogicalUnion(all=[false]), id = 19
> LogicalProject(X=[$0], Y=[$1]), id = 16
> LogicalUnion(all=[true]), id = 15
> LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 12
> LogicalValues(tuples=[[{ 0 }]]), id = 11
> LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 14
> LogicalValues(tuples=[[{ 0 }]]), id = 13
> LogicalProject(X=[null:INTEGER], Y=[null:VARCHAR(1)]), id = 18
> LogicalValues(tuples=[[{ 0 }]]), id = 17
> {code}
> after optimize, the relnode tree is as follows,
> {code:java}
> LogicalUnion(all=[false]), id = 30
> LogicalProject(X=[$0], Y=[$1]), id = 26
> LogicalUnion(all=[true]), id = 24
> LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 21
> LogicalValues(tuples=[[{ 0 }]]), id = 11
>
[jira] [Comment Edited] (CALCITE-3413) AssertionError for interpertering union/intersect/minus with null value
[
https://issues.apache.org/jira/browse/CALCITE-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951926#comment-16951926
]
Wang Yanlin edited comment on CALCITE-3413 at 10/15/19 1:37 PM:
Fix together with https://issues.apache.org/jira/browse/CALCITE-3407 in the
same PR.
Just close this jira.
was (Author: yanlin-lynn):
Fix together with https://issues.apache.org/jira/browse/CALCITE-3407 in the
same PR.
> AssertionError for interpertering union/intersect/minus with null value
> ---
>
> Key: CALCITE-3413
> URL: https://issues.apache.org/jira/browse/CALCITE-3413
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> Add the following test case in *InterpreterTest*
> {code:java}
> @Test public void testInterpretUnionWithNullValue() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1))),\n"
> + "(cast(NULL as int), cast(NULL as varchar(1 as t(x, y))\n"
> + "union\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1 as t2(x, y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[null, null]");
> }
> @Test public void testInterpretUnionAllWithNullValue() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1))),\n"
> + "(cast(NULL as int), cast(NULL as varchar(1 as t(x, y))\n"
> + "union all\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1 as t2(x, y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[null, null]", "[null, null]", "[null, null]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.source(Interpreter.java:510)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.source(Nodes.java:46)
> at
> org.apache.calcite.interpreter.AbstractSingleNode.(AbstractSingleNode.java:33)
> at
> org.apache.calcite.interpreter.ProjectNode.(ProjectNode.java:31)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:60)
> 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.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:257)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:214)
> at
> org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:464)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:451)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:46)
> at
> org.apache.calcite.rel.AbstractRelNode.childrenAccept(AbstractRelNode.java:265)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:447)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:46)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:405)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:88)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretMinusWithNullValue(InterpreterTest.java:418)
> {code}
> The cause lies in the optimize of
> [Interpreter|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/interpreter/Interpreter.java#L85]
> before optimize, the relnode tree is as follows, no renode with same id exists
> {code:java}
> LogicalUnion(all=[false]), id = 19
> LogicalProject(X=[$0], Y=[$1]), id = 16
> LogicalUnion(all=[true]), id = 15
> LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 12
> LogicalValues(tuples=[[{ 0 }]]), id = 11
> LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 14
> LogicalValues(tuples=[[{ 0 }]]), id = 13
> LogicalProject(X=[null:INTEGER], Y=[null:VARCHAR(1)]), id = 18
> LogicalValues(tuples=[[{ 0 }]]), id = 17
> {code}
> after optimize, the relnode tree is as follows,
>
[jira] [Commented] (CALCITE-3413) AssertionError for interpertering union/intersect/minus with null value
[
https://issues.apache.org/jira/browse/CALCITE-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951926#comment-16951926
]
Wang Yanlin commented on CALCITE-3413:
--
Fix together with https://issues.apache.org/jira/browse/CALCITE-3407 in the
same PR.
> AssertionError for interpertering union/intersect/minus with null value
> ---
>
> Key: CALCITE-3413
> URL: https://issues.apache.org/jira/browse/CALCITE-3413
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> Add the following test case in *InterpreterTest*
> {code:java}
> @Test public void testInterpretUnionWithNullValue() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1))),\n"
> + "(cast(NULL as int), cast(NULL as varchar(1 as t(x, y))\n"
> + "union\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1 as t2(x, y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[null, null]");
> }
> @Test public void testInterpretUnionAllWithNullValue() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1))),\n"
> + "(cast(NULL as int), cast(NULL as varchar(1 as t(x, y))\n"
> + "union all\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1 as t2(x, y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[null, null]", "[null, null]", "[null, null]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.source(Interpreter.java:510)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.source(Nodes.java:46)
> at
> org.apache.calcite.interpreter.AbstractSingleNode.(AbstractSingleNode.java:33)
> at
> org.apache.calcite.interpreter.ProjectNode.(ProjectNode.java:31)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:60)
> 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.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:257)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:214)
> at
> org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:464)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:451)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:46)
> at
> org.apache.calcite.rel.AbstractRelNode.childrenAccept(AbstractRelNode.java:265)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:447)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:46)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:405)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:88)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretMinusWithNullValue(InterpreterTest.java:418)
> {code}
> The cause lies in the optimize of
> [Interpreter|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/interpreter/Interpreter.java#L85]
> before optimize, the relnode tree is as follows, no renode with same id exists
> {code:java}
> LogicalUnion(all=[false]), id = 19
> LogicalProject(X=[$0], Y=[$1]), id = 16
> LogicalUnion(all=[true]), id = 15
> LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 12
> LogicalValues(tuples=[[{ 0 }]]), id = 11
> LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 14
> LogicalValues(tuples=[[{ 0 }]]), id = 13
> LogicalProject(X=[null:INTEGER], Y=[null:VARCHAR(1)]), id = 18
> LogicalValues(tuples=[[{ 0 }]]), id = 17
> {code}
> after optimize, the relnode tree is as follows,
> {code:java}
> LogicalUnion(all=[false]), id = 30
> LogicalProject(X=[$0], Y=[$1]), id = 26
> LogicalUnion(all=[true]), id = 24
> LogicalProject(EXPR$0=[null:INTEGER],
[jira] [Commented] (CALCITE-3414) Unify Expression'type cast and conversion as a robust one
[
https://issues.apache.org/jira/browse/CALCITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951893#comment-16951893
]
Danny Chen commented on CALCITE-3414:
-
I'm inclined to move the Types#castIfNecessary into Calcite core, and use the
RexToLixTranslator#convert as the last fallback invocation. Then we should
always use Types#castIfNecessary instead of RexToLixTranslator#convert.
> Unify Expression'type cast and conversion as a robust one
> -
>
> Key: CALCITE-3414
> URL: https://issues.apache.org/jira/browse/CALCITE-3414
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Attachments: RexToLixTranslator.png, TypeConversion.txt, Types.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current now, there are two functions in calcite that can be used to
> cast/convert Expression to a specific Type.
> *_Types.castIfNecessary_* and _*RexToLixTranslator.convert*_.
> We make a deep investigation on their implementations and demonstrate them as
> below.
> {color:#ff}
> !RexToLixTranslator.png!{color}
> {color:#ff}
> *RexToLixTranslator.convert*{color}
> !Types.png!
> {color:#ff}
> *Types.castIfNecessary*{color}
> It can be seen that:
> (1) They have a lot of overlaps;
> (2) *_RexToLixTranslator.cast_* can cover more cases with tools like
> _SqlFunctions_ and etc.
> (3) Both of them have limitations and may generate incorrect code, which is
> listed in attachment(TypeConversion.txt).
> Multiple choices usually bring confusion to developers and resulting to the
> misuse of them.
> For example, CALCITE-3245 exposes that Types.castIfNecessary cannot cast the
> Expression to BigDecimal.class.
> Fixing the issue in *_Types.castIfNecessary_* directly seems to be not a
> good idea.
> On one hand, it is not convenient to call _SqlFunctions_ in linq4j. One the
> other hand, it will brings duplicate with _*RexToLixTranslator.cast*_.
> However, due to some unique logic in _*Types.castIfNecessary*_, we cannot
> replace it as _*RexToLixTranslator.cast*_ neither.
> Therefore, it is a good idea to integrate implementations into
> RexToLixTranslator.cast.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3414) Unify Expression'type cast and conversion as a robust one
[
https://issues.apache.org/jira/browse/CALCITE-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3414:
Labels: pull-request-available (was: )
> Unify Expression'type cast and conversion as a robust one
> -
>
> Key: CALCITE-3414
> URL: https://issues.apache.org/jira/browse/CALCITE-3414
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Feng Zhu
>Assignee: Feng Zhu
>Priority: Major
> Labels: pull-request-available
> Attachments: RexToLixTranslator.png, TypeConversion.txt, Types.png
>
>
> Current now, there are two functions in calcite that can be used to
> cast/convert Expression to a specific Type.
> *_Types.castIfNecessary_* and _*RexToLixTranslator.convert*_.
> We make a deep investigation on their implementations and demonstrate them as
> below.
> {color:#ff}
> !RexToLixTranslator.png!{color}
> {color:#ff}
> *RexToLixTranslator.convert*{color}
> !Types.png!
> {color:#ff}
> *Types.castIfNecessary*{color}
> It can be seen that:
> (1) They have a lot of overlaps;
> (2) *_RexToLixTranslator.cast_* can cover more cases with tools like
> _SqlFunctions_ and etc.
> (3) Both of them have limitations and may generate incorrect code, which is
> listed in attachment(TypeConversion.txt).
> Multiple choices usually bring confusion to developers and resulting to the
> misuse of them.
> For example, CALCITE-3245 exposes that Types.castIfNecessary cannot cast the
> Expression to BigDecimal.class.
> Fixing the issue in *_Types.castIfNecessary_* directly seems to be not a
> good idea.
> On one hand, it is not convenient to call _SqlFunctions_ in linq4j. One the
> other hand, it will brings duplicate with _*RexToLixTranslator.cast*_.
> However, due to some unique logic in _*Types.castIfNecessary*_, we cannot
> replace it as _*RexToLixTranslator.cast*_ neither.
> Therefore, it is a good idea to integrate implementations into
> RexToLixTranslator.cast.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3414) Unify Expression'type cast and conversion as a robust one
Feng Zhu created CALCITE-3414:
-
Summary: Unify Expression'type cast and conversion as a robust one
Key: CALCITE-3414
URL: https://issues.apache.org/jira/browse/CALCITE-3414
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.21.0
Reporter: Feng Zhu
Assignee: Feng Zhu
Attachments: RexToLixTranslator.png, TypeConversion.txt, Types.png
Current now, there are two functions in calcite that can be used to
cast/convert Expression to a specific Type.
*_Types.castIfNecessary_* and _*RexToLixTranslator.convert*_.
We make a deep investigation on their implementations and demonstrate them as
below.
{color:#ff}
!RexToLixTranslator.png!{color}
{color:#ff}
*RexToLixTranslator.convert*{color}
!Types.png!
{color:#ff}
*Types.castIfNecessary*{color}
It can be seen that:
(1) They have a lot of overlaps;
(2) *_RexToLixTranslator.cast_* can cover more cases with tools like
_SqlFunctions_ and etc.
(3) Both of them have limitations and may generate incorrect code, which is
listed in attachment(TypeConversion.txt).
Multiple choices usually bring confusion to developers and resulting to the
misuse of them.
For example, CALCITE-3245 exposes that Types.castIfNecessary cannot cast the
Expression to BigDecimal.class.
Fixing the issue in *_Types.castIfNecessary_* directly seems to be not a good
idea.
On one hand, it is not convenient to call _SqlFunctions_ in linq4j. One the
other hand, it will brings duplicate with _*RexToLixTranslator.cast*_. However,
due to some unique logic in _*Types.castIfNecessary*_, we cannot replace it as
_*RexToLixTranslator.cast*_ neither.
Therefore, it is a good idea to integrate implementations into
RexToLixTranslator.cast.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3334) Refinement for Substitution-Based MV Matching
[ https://issues.apache.org/jira/browse/CALCITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jin xing reassigned CALCITE-3334: - Assignee: jin xing > Refinement for Substitution-Based MV Matching > - > > Key: CALCITE-3334 > URL: https://issues.apache.org/jira/browse/CALCITE-3334 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: jin xing >Assignee: jin xing >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > > The approach of substitution-based MV matching is an effective way for its > simplicity and extensibility. > This JIRA proposes to refine existing implementation by several points: > # Canonicalize before MV matching -- by such canonicalization we can > significantly simplify the algebra tree and lower the difficulty for > materialization matching. > # Separate matching rules into two categories and enumerate common matching > patterns which need to be covered by rules. > Please check the design doc: [Design > Doc|https://docs.google.com/document/d/1JpwGNFE3hw3yXb7W3-95-jXKClZC5UFPKbuhgYDuEu4/edit#] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3412) Response Error for FLOOR TIMESTAMP TO WEEK
[
https://issues.apache.org/jira/browse/CALCITE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huaicui updated CALCITE-3412:
-
Description:
Floor timestamp to week exist error:
The start day of the week is not Sunday or Monday, calcite use Thursday to
split a week.
Example:
sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
Response:
2017-01-26 00:00:00.0
2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
the first day that we expect.
was:
Floor timestamp to week exist error:
The start day of the week is not Sunday or Monday, calcite use Tuesday to split
a week.
Example:
sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
Response:
2017-01-26 00:00:00.0
2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
the first day that we expect.
> Response Error for FLOOR TIMESTAMP TO WEEK
> ---
>
> Key: CALCITE-3412
> URL: https://issues.apache.org/jira/browse/CALCITE-3412
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: mac,linux
>Reporter: huaicui
>Priority: Major
> Attachments: image-2019-10-15-13-33-34-896.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Floor timestamp to week exist error:
> The start day of the week is not Sunday or Monday, calcite use Thursday to
> split a week.
> Example:
> sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
> Response:
> 2017-01-26 00:00:00.0
>
> 2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
> the first day that we expect.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3412) Response Error for FLOOR TIMESTAMP TO WEEK
[
https://issues.apache.org/jira/browse/CALCITE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951750#comment-16951750
]
huaicui commented on CALCITE-3412:
--
We have provided a date and want to get the date of the first day of the
week，but the result is the date of this Thursday.
Mysql Example:
If the week starts on Sunday do this:
select DATE_ADD(now(), INTERVAL(1-DAYOFWEEK(now())) DAY)
If the week starts on Monday do this:
select DATE_ADD(now(), INTERVAL(-WEEKDAY(now())) DAY);
We use this sql of the calcite to get what we want:
select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK)
But the result is the date of this Thursday.
Can you give suggestion to fix that?
> Response Error for FLOOR TIMESTAMP TO WEEK
> ---
>
> Key: CALCITE-3412
> URL: https://issues.apache.org/jira/browse/CALCITE-3412
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: mac,linux
>Reporter: huaicui
>Priority: Major
> Attachments: image-2019-10-15-13-33-34-896.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Floor timestamp to week exist error:
> The start day of the week is not Sunday or Monday, calcite use Tuesday to
> split a week.
> Example:
> sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
> Response:
> 2017-01-26 00:00:00.0
>
> 2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
> the first day that we expect.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3413) AssertionError for interpertering union/intersect/minus with null value
[
https://issues.apache.org/jira/browse/CALCITE-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin updated CALCITE-3413:
-
Issue Type: Bug (was: New Feature)
> AssertionError for interpertering union/intersect/minus with null value
> ---
>
> Key: CALCITE-3413
> URL: https://issues.apache.org/jira/browse/CALCITE-3413
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Major
>
> Add the following test case in *InterpreterTest*
> {code:java}
> @Test public void testInterpretUnionWithNullValue() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1))),\n"
> + "(cast(NULL as int), cast(NULL as varchar(1 as t(x, y))\n"
> + "union\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1 as t2(x, y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[null, null]");
> }
> @Test public void testInterpretUnionAllWithNullValue() throws Exception {
> final String sql = "select * from\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1))),\n"
> + "(cast(NULL as int), cast(NULL as varchar(1 as t(x, y))\n"
> + "union all\n"
> + "(select x, y from (values (cast(NULL as int), cast(NULL as
> varchar(1 as t2(x, y))\n";
> SqlNode validate = planner.validate(planner.parse(sql));
> RelNode convert = planner.rel(validate).rel;
> final Interpreter interpreter = new Interpreter(dataContext, convert);
> assertRows(interpreter, "[null, null]", "[null, null]", "[null, null]");
> }
> {code}
> got
> {code:java}
> java.lang.AssertionError
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.source(Interpreter.java:510)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.source(Nodes.java:46)
> at
> org.apache.calcite.interpreter.AbstractSingleNode.(AbstractSingleNode.java:33)
> at
> org.apache.calcite.interpreter.ProjectNode.(ProjectNode.java:31)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:60)
> 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.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:257)
> at
> org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:214)
> at
> org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:464)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:451)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:46)
> at
> org.apache.calcite.rel.AbstractRelNode.childrenAccept(AbstractRelNode.java:265)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:447)
> at
> org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:46)
> at
> org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:405)
> at
> org.apache.calcite.interpreter.Interpreter.(Interpreter.java:88)
> at
> org.apache.calcite.test.InterpreterTest.testInterpretMinusWithNullValue(InterpreterTest.java:418)
> {code}
> The cause lies in the optimize of
> [Interpreter|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/interpreter/Interpreter.java#L85]
> before optimize, the relnode tree is as follows, no renode with same id exists
> {code:java}
> LogicalUnion(all=[false]), id = 19
> LogicalProject(X=[$0], Y=[$1]), id = 16
> LogicalUnion(all=[true]), id = 15
> LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 12
> LogicalValues(tuples=[[{ 0 }]]), id = 11
> LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 14
> LogicalValues(tuples=[[{ 0 }]]), id = 13
> LogicalProject(X=[null:INTEGER], Y=[null:VARCHAR(1)]), id = 18
> LogicalValues(tuples=[[{ 0 }]]), id = 17
> {code}
> after optimize, the relnode tree is as follows,
> {code:java}
> LogicalUnion(all=[false]), id = 30
> LogicalProject(X=[$0], Y=[$1]), id = 26
> LogicalUnion(all=[true]), id = 24
> LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 21
> LogicalValues(tuples=[[{ 0 }]]), id = 11
>
[jira] [Updated] (CALCITE-3412) Response Error for FLOOR TIMESTAMP TO WEEK
[
https://issues.apache.org/jira/browse/CALCITE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huaicui updated CALCITE-3412:
-
Description:
Floor timestamp to week exist error:
The start day of the week is not Sunday or Monday, calcite use Tuesday to split
a week.
Example:
sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
Response:
2017-01-26 00:00:00.0
2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
the first day that is we expect.
was:
Floor timestamp to week exist error:
The start day of the week is not Sunday or Monday, calcite use Tuesday to split
a week.
Example:
sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
Response:
2017-01-26 00:00:00.0
2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
what we expect.
> Response Error for FLOOR TIMESTAMP TO WEEK
> ---
>
> Key: CALCITE-3412
> URL: https://issues.apache.org/jira/browse/CALCITE-3412
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: mac,linux
>Reporter: huaicui
>Priority: Major
> Attachments: image-2019-10-15-13-33-34-896.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Floor timestamp to week exist error:
> The start day of the week is not Sunday or Monday, calcite use Tuesday to
> split a week.
> Example:
> sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
> Response:
> 2017-01-26 00:00:00.0
>
> 2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
> the first day that is we expect.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3412) Response Error for FLOOR TIMESTAMP TO WEEK
[
https://issues.apache.org/jira/browse/CALCITE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huaicui updated CALCITE-3412:
-
Description:
Floor timestamp to week exist error:
The start day of the week is not Sunday or Monday, calcite use Tuesday to split
a week.
Example:
sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
Response:
2017-01-26 00:00:00.0
2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
the first day that we expect.
was:
Floor timestamp to week exist error:
The start day of the week is not Sunday or Monday, calcite use Tuesday to split
a week.
Example:
sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
Response:
2017-01-26 00:00:00.0
2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
the first day that is we expect.
> Response Error for FLOOR TIMESTAMP TO WEEK
> ---
>
> Key: CALCITE-3412
> URL: https://issues.apache.org/jira/browse/CALCITE-3412
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: mac,linux
>Reporter: huaicui
>Priority: Major
> Attachments: image-2019-10-15-13-33-34-896.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Floor timestamp to week exist error:
> The start day of the week is not Sunday or Monday, calcite use Tuesday to
> split a week.
> Example:
> sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
> Response:
> 2017-01-26 00:00:00.0
>
> 2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
> the first day that we expect.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3412) Response Error for FLOOR TIMESTAMP TO WEEK
[
https://issues.apache.org/jira/browse/CALCITE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
huaicui updated CALCITE-3412:
-
Description:
Floor timestamp to week exist error:
The start day of the week is not Sunday or Monday, calcite use Tuesday to split
a week.
Example:
sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
Response:
2017-01-26 00:00:00.0
2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
what we expect.
was:
The start day of the week is not Sunday or Monday, calcite use Tuesday to split
a week, like this:
select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
The response is :
2017-01-26 00:00:00.0
2017-01-26 is Tuesday.
> Response Error for FLOOR TIMESTAMP TO WEEK
> ---
>
> Key: CALCITE-3412
> URL: https://issues.apache.org/jira/browse/CALCITE-3412
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: mac,linux
>Reporter: huaicui
>Priority: Major
> Attachments: image-2019-10-15-13-33-34-896.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Floor timestamp to week exist error:
> The start day of the week is not Sunday or Monday, calcite use Tuesday to
> split a week.
> Example:
> sql: select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
> Response:
> 2017-01-26 00:00:00.0
>
> 2017-01-26 is Tuesday that is not our expect result. As result, 2017-01-22 is
> what we expect.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (CALCITE-3403) WindowReduceExpressionsRule does not reuse RelMetadataQuery
[ https://issues.apache.org/jira/browse/CALCITE-3403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jin xing reassigned CALCITE-3403: - Assignee: jin xing > WindowReduceExpressionsRule does not reuse RelMetadataQuery > --- > > Key: CALCITE-3403 > URL: https://issues.apache.org/jira/browse/CALCITE-3403 > Project: Calcite > Issue Type: Improvement >Reporter: Haisheng Yuan >Assignee: jin xing >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > It creates a new RelMetadataQuery instance, which is a fresh RelMetadataQuery > without any data cache. We should get RelMetadataQuery from RelOptRuleCall to > reuse cache as much as possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3412) Response Error for FLOOR TIMESTAMP TO WEEK
[
https://issues.apache.org/jira/browse/CALCITE-3412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951666#comment-16951666
]
Danny Chen commented on CALCITE-3412:
-
I'm curious what is the right start day of a week, Sunday ?
> Response Error for FLOOR TIMESTAMP TO WEEK
> ---
>
> Key: CALCITE-3412
> URL: https://issues.apache.org/jira/browse/CALCITE-3412
> Project: Calcite
> Issue Type: Bug
> Components: core
> Environment: mac,linux
>Reporter: huaicui
>Priority: Major
> Attachments: image-2019-10-15-13-33-34-896.png
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The start day of the week is not Sunday or Monday, calcite use Tuesday to
> split a week, like this:
> select FLOOR(CAST('2017-01-28' AS TIMESTAMP) TO WEEK);
> The response is :
> 2017-01-26 00:00:00.0
> 2017-01-26 is Tuesday.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3413) AssertionError for interpertering union/intersect/minus with null value
Wang Yanlin created CALCITE-3413:
Summary: AssertionError for interpertering union/intersect/minus
with null value
Key: CALCITE-3413
URL: https://issues.apache.org/jira/browse/CALCITE-3413
Project: Calcite
Issue Type: New Feature
Reporter: Wang Yanlin
Add the following test case in *InterpreterTest*
{code:java}
@Test public void testInterpretUnionWithNullValue() throws Exception {
final String sql = "select * from\n"
+ "(select x, y from (values (cast(NULL as int), cast(NULL as
varchar(1))),\n"
+ "(cast(NULL as int), cast(NULL as varchar(1 as t(x, y))\n"
+ "union\n"
+ "(select x, y from (values (cast(NULL as int), cast(NULL as
varchar(1 as t2(x, y))\n";
SqlNode validate = planner.validate(planner.parse(sql));
RelNode convert = planner.rel(validate).rel;
final Interpreter interpreter = new Interpreter(dataContext, convert);
assertRows(interpreter, "[null, null]");
}
@Test public void testInterpretUnionAllWithNullValue() throws Exception {
final String sql = "select * from\n"
+ "(select x, y from (values (cast(NULL as int), cast(NULL as
varchar(1))),\n"
+ "(cast(NULL as int), cast(NULL as varchar(1 as t(x, y))\n"
+ "union all\n"
+ "(select x, y from (values (cast(NULL as int), cast(NULL as
varchar(1 as t2(x, y))\n";
SqlNode validate = planner.validate(planner.parse(sql));
RelNode convert = planner.rel(validate).rel;
final Interpreter interpreter = new Interpreter(dataContext, convert);
assertRows(interpreter, "[null, null]", "[null, null]", "[null, null]");
}
{code}
got
{code:java}
java.lang.AssertionError
at
org.apache.calcite.interpreter.Interpreter$CompilerImpl.source(Interpreter.java:510)
at
org.apache.calcite.interpreter.Nodes$CoreCompiler.source(Nodes.java:46)
at
org.apache.calcite.interpreter.AbstractSingleNode.(AbstractSingleNode.java:33)
at
org.apache.calcite.interpreter.ProjectNode.(ProjectNode.java:31)
at
org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:60)
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.apache.calcite.util.ReflectUtil.invokeVisitorInternal(ReflectUtil.java:257)
at
org.apache.calcite.util.ReflectUtil.invokeVisitor(ReflectUtil.java:214)
at
org.apache.calcite.util.ReflectUtil$1.invokeVisitor(ReflectUtil.java:464)
at
org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:451)
at
org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:46)
at
org.apache.calcite.rel.AbstractRelNode.childrenAccept(AbstractRelNode.java:265)
at
org.apache.calcite.interpreter.Interpreter$CompilerImpl.visit(Interpreter.java:447)
at
org.apache.calcite.interpreter.Nodes$CoreCompiler.visit(Nodes.java:46)
at
org.apache.calcite.interpreter.Interpreter$CompilerImpl.visitRoot(Interpreter.java:405)
at
org.apache.calcite.interpreter.Interpreter.(Interpreter.java:88)
at
org.apache.calcite.test.InterpreterTest.testInterpretMinusWithNullValue(InterpreterTest.java:418)
{code}
The cause lies in the optimize of
[Interpreter|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/interpreter/Interpreter.java#L85]
before optimize, the relnode tree is as follows, no renode with same id exists
{code:java}
LogicalUnion(all=[false]), id = 19
LogicalProject(X=[$0], Y=[$1]), id = 16
LogicalUnion(all=[true]), id = 15
LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 12
LogicalValues(tuples=[[{ 0 }]]), id = 11
LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 14
LogicalValues(tuples=[[{ 0 }]]), id = 13
LogicalProject(X=[null:INTEGER], Y=[null:VARCHAR(1)]), id = 18
LogicalValues(tuples=[[{ 0 }]]), id = 17
{code}
after optimize, the relnode tree is as follows,
{code:java}
LogicalUnion(all=[false]), id = 30
LogicalProject(X=[$0], Y=[$1]), id = 26
LogicalUnion(all=[true]), id = 24
LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 21
LogicalValues(tuples=[[{ 0 }]]), id = 11
LogicalProject(EXPR$0=[null:INTEGER], EXPR$1=[null:VARCHAR(1)]), id = 21
LogicalValues(tuples=[[{ 0 }]]), id = 11
LogicalProject(X=[null:INTEGER], Y=[null:VARCHAR(1)]), id = 28
LogicalValues(tuples=[[{ 0 }]]), id = 11
{code}
there exists relnodes with same id, thus breaking the inner structure of
[jira] [Comment Edited] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951659#comment-16951659 ] hailin.huang edited comment on CALCITE-1075 at 10/15/19 7:03 AM: - [~julianhyde] Hi Julian Hyde, Do we fix this issue now? And I found that Hive use Object type to return and in jdbc, when call getDate, firstly it call getObject() and then covert it to Date, which might be a good way. was (Author: aahi): [~julianhyde] Hi Julian Hyde, Do we fix this issue now? And I found that Hive use Object type to reture and in jdbc, when call getDate, firstly it call getObject() and then covert it to Date, which might be a good way. > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at testPs.TestPs.main(TestPs.java:150) > > 3. UDFs with same name and different arg types > UDF： DATE_TRUNC（Timestamp D, String x） returns a timestamp value > DATE_TRUNC(Date D, String x) returns a date value > > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > Error stack： > Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, > column 11 to line 1, column 32: Cannot apply 'DATE_TRUNC' to arguments of > type 'DATE_TRUNC(, )'. Supported form(s): > 'DATE_TRUNC(, )' > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:715) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:703) > at >
[jira] [Comment Edited] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951659#comment-16951659 ] hailin.huang edited comment on CALCITE-1075 at 10/15/19 7:02 AM: - [~julianhyde] Hi Julian Hyde, Do we fix this issue now? And I found that Hive use Object type to reture and in jdbc, when call getDate, firstly it call getObject() and then covert it to Date, which might be a good way. was (Author: aahi): [~julianhyde] Hi Julian Hyde, Do we fix this issue? > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at testPs.TestPs.main(TestPs.java:150) > > 3. UDFs with same name and different arg types > UDF： DATE_TRUNC（Timestamp D, String x） returns a timestamp value > DATE_TRUNC(Date D, String x) returns a date value > > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > Error stack： > Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, > column 11 to line 1, column 32: Cannot apply 'DATE_TRUNC' to arguments of > type 'DATE_TRUNC(, )'. Supported form(s): > 'DATE_TRUNC(, )' > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:715) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:703) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:3932) > at >
[jira] [Commented] (CALCITE-1075) UDF Error of Calcite 1.6
[ https://issues.apache.org/jira/browse/CALCITE-1075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951659#comment-16951659 ] hailin.huang commented on CALCITE-1075: --- [~julianhyde] Hi Julian Hyde, Do we fix this issue? > UDF Error of Calcite 1.6 > - > > Key: CALCITE-1075 > URL: https://issues.apache.org/jira/browse/CALCITE-1075 > Project: Calcite > Issue Type: Bug >Affects Versions: 1.6.0 >Reporter: Wei Hu >Priority: Major > Attachments: 0001-test-cases-for-CALCITE-1075.patch > > > UDF Error In Calcite 1.6, may be Regression bugs? > schema：Table:hr, A String， B String， C String， D Timestamp > UDF： DATE_TRUNC（Timestamp D, String X） returns a timestamp value > there a several regression bugs. 1.5 is ok, but 1.6 will throw exception: > 1. UDF in Group_by clause, > sql：select min(m0), max(m0) from (select DATE_TRUNC(D, 'month') as d1, > COUNT(A) as m0 from \"hr\" group by DATE_TRUNC(D, 'month')) > Error Stack： > Caused by: java.lang.ClassCastException: java.sql.Timestamp cannot be cast to > java.lang.Long > at Baz$2.apply(Unknown Source) > at Baz$2.apply(Unknown Source) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy_(EnumerableDefaults.java:821) > at > org.apache.calcite.linq4j.EnumerableDefaults.groupBy(EnumerableDefaults.java:754) > at > org.apache.calcite.linq4j.DefaultEnumerable.groupBy(DefaultEnumerable.java:302) > at Baz.bind(Unknown Source) > at > org.apache.calcite.jdbc.CalcitePrepare$CalciteSignature.enumerable(CalcitePrepare.java:326) > at > org.apache.calcite.jdbc.CalciteConnectionImpl.enumerable(CalciteConnectionImpl.java:281) > at > org.apache.calcite.jdbc.CalciteMetaImpl._createIterable(CalciteMetaImpl.java:545) > at > org.apache.calcite.jdbc.CalciteMetaImpl.createIterable(CalciteMetaImpl.java:536) > at > org.apache.calcite.avatica.AvaticaResultSet.execute(AvaticaResultSet.java:187) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:65) > at > org.apache.calcite.jdbc.CalciteResultSet.execute(CalciteResultSet.java:44) > at > org.apache.calcite.avatica.AvaticaConnection$1.execute(AvaticaConnection.java:566) > at > org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:578) > at > org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:571) > at > org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:135) > ... 2 more > > > 2. select UDF > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > throw exception when call resultSet.getTimestamp(1) > Error stack: > Exception in thread "main" java.lang.ClassCastException: java.sql.Timestamp > cannot be cast to java.lang.Number > at > org.apache.calcite.avatica.util.AbstractCursor$NumberAccessor.getNumber(AbstractCursor.java:696) > at > org.apache.calcite.avatica.util.AbstractCursor$TimestampFromNumberAccessor.getTimestamp(AbstractCursor.java:958) > at > org.apache.calcite.avatica.AvaticaResultSet.getTimestamp(AvaticaResultSet.java:285) > at testPs.TestPs.main(TestPs.java:150) > > 3. UDFs with same name and different arg types > UDF： DATE_TRUNC（Timestamp D, String x） returns a timestamp value > DATE_TRUNC(Date D, String x) returns a date value > > sql: select D, DATE_TRUNC(D, 'month') from \"hr\" group by D > Error stack： > Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, > column 11 to line 1, column 32: Cannot apply 'DATE_TRUNC' to arguments of > type 'DATE_TRUNC(, )'. Supported form(s): > 'DATE_TRUNC(, )' > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > at > org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:405) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:715) > at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:703) > at > org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:3932) > at > org.apache.calcite.sql.SqlCallBinding.newValidationSignatureError(SqlCallBinding.java:275) > at > org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkSingleOperandType(FamilyOperandTypeChecker.java:92) > at > org.apache.calcite.sql.type.FamilyOperandTypeChecker.checkOperandTypes(FamilyOperandTypeChecker.java:109) > at >
