[jira] [Commented] (CALCITE-5713) SqlBasicCall's Deep Copy Logic Raises Rule Optimization Exception
[
https://issues.apache.org/jira/browse/CALCITE-5713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759190#comment-17759190
]
Guoliang Sun commented on CALCITE-5713:
---
Thanks for the reply, having faced customer problems head on for so long has
gotten me into the habit of working backwards to a solution, and you've woken
me up.
This has benefited me a lot and I appreciate it.
I will think about other ways to solve the problem and redesign the test cases.
> SqlBasicCall's Deep Copy Logic Raises Rule Optimization Exception
> -
>
> Key: CALCITE-5713
> URL: https://issues.apache.org/jira/browse/CALCITE-5713
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Guoliang Sun
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> h3. Background
> In the fix for
> [CALCITE-4795,|https://issues.apache.org/jira/browse/CALCITE-4795] the
> operands in the SqlBasicCall class were changed from SqlNode[] to
> ImmutableNullableList. Also change the variable name to operandList, and add
> a new set method to modify the elements in the collection.
> h3. Exception
> Take the following SQL as an example
> {code:sql}
> SELECT { fn TRUNCATE(
> { fn QUARTER(
> { fn TIMESTAMPADD(
> SQL_TSI_HOUR,
> 1,
> { ts '1900-01-01 00:00:00' }
> ) }
> ) },
> 0
> ) }
> FROM "TDVT"."CALCS" "CALCS"
> GROUP BY 1.1001
> {code}
> An exception is thrown when the optimization execution reaches the
> CoreRules.PROJECT_REDUCE_EXPRESSIONS rule: {color:#DE350B}cannot translate
> call QUARTER($t4){color}
> h3. RootCause
> The SqlBasicCall#set method uses a deep copy in order to modify immutable
> collections and returns a new operandList object when modified.
> If the SQL contains an operation that requires a rewrite call, such as
> QUARTER in the above SQL, the deep copy logic will cause the operator and
> operandList to be different and eventually raise an exception.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5953) AggregateCaseToFilterRule may make inaccurate SUM transformation
[
https://issues.apache.org/jira/browse/CALCITE-5953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759156#comment-17759156
]
Julian Hyde commented on CALCITE-5953:
--
[~libenchao],
{quote}So returning NULL could give us more information than 0.{quote}
I agree. SUM returns more information than SUM0. As implementors, we have to
retain that extra information, and that makes our implementation more complex.
If the user doesn't want to distinguish "a total that is 0 because there were
no rows" from "a total that is zero because the rows (if any) summed to zero"
then we would like to give them an efficient implementation but we can't
because they wrote SUM.
> AggregateCaseToFilterRule may make inaccurate SUM transformation
>
>
> Key: CALCITE-5953
> URL: https://issues.apache.org/jira/browse/CALCITE-5953
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> consider: {{sum(case when x = 1 then 2 else 0 end) as b}}
> notice that this expression may only be null if there are no rows in the table
> {{AggregateCaseToFilterRule}} rewrites the above expression to {{sum(1)
> filter (where x=2)}} which broadens when it could be `null` to when there are
> no matches to the filter
> * *A* is *0* correctly in this case; but I think it will be still *0* in case
> there are 0 input rows
> * The result for *B* supposed to be *0* but since there are no matches by the
> filter it becomes *null*
> * *C* is not touched
> {code}
> # Convert CASE to FILTER without matches
> select sum(case when x = 1 then 1 else 0 end) as a,
> sum(case when x = 1 then 2 else 0 end) as b,
> sum(case when x = 1 then 3 else -1 end) as c
> from (values 0, null, 0, 2) as t(x);
> +---+---++
> | A | B | C |
> +---+---++
> | 0 | 0 | -4 |
> +---+---++
> (1 row)
> !ok
> EnumerableCalc(expr#0..2=[{inputs}], expr#3=[CAST($t0):INTEGER], A=[$t3],
> B=[$t1], C=[$t2])
> EnumerableAggregate(group=[{}], A=[COUNT() FILTER $1], B=[SUM($2) FILTER
> $3], C=[SUM($0)])
> EnumerableCalc(expr#0=[{inputs}], expr#1=[1], expr#2=[=($t0, $t1)],
> expr#3=[3], expr#4=[-1], expr#5=[CASE($t2, $t3, $t4)], expr#6=[IS TRUE($t2)],
> expr#7=[2], $f2=[$t5], $f3=[$t6], $f4=[$t7], $f5=[$t6])
> EnumerableValues(tuples=[[{ 0 }, { null }, { 0 }, { 2 }]])
> !plan
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5953) AggregateCaseToFilterRule may make inaccurate SUM transformation
[
https://issues.apache.org/jira/browse/CALCITE-5953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759155#comment-17759155
]
Julian Hyde commented on CALCITE-5953:
--
The following cases seem safe (please check my reasoning!) and worth applying
the transformation.
1. Transform either of
{code:java}
SELECT SUM(CASE WHEN c THEN x END) ...;
SELECT SUM(CASE WHEN c THEN x ELSE null END) ...;
{code}
into
{code:java}
SELECT SUM(x) FILTER (WHERE c) ...
{code}
2. Transform any of
{code:java}
SELECT COALESCE(SUM(CASE WHEN c THEN x ELSE 0 END), 0) ...;
SELECT NVL(SUM(CASE WHEN c THEN x ELSE 0 END), 0) ...;
SELECT SUM0(CASE WHEN c THEN x ELSE 0 END) ...;
{code}
into
{code:java}
SELECT SUM0(x) FILTER (WHERE c)
{code}
I don't think it's worth doing rewrites that make the expression more complex.
The complexity of the expressions will make it difficult to apply further
optimizations.
> AggregateCaseToFilterRule may make inaccurate SUM transformation
>
>
> Key: CALCITE-5953
> URL: https://issues.apache.org/jira/browse/CALCITE-5953
> Project: Calcite
> Issue Type: Bug
>Reporter: Zoltan Haindrich
>Assignee: Zoltan Haindrich
>Priority: Major
>
> consider: {{sum(case when x = 1 then 2 else 0 end) as b}}
> notice that this expression may only be null if there are no rows in the table
> {{AggregateCaseToFilterRule}} rewrites the above expression to {{sum(1)
> filter (where x=2)}} which broadens when it could be `null` to when there are
> no matches to the filter
> * *A* is *0* correctly in this case; but I think it will be still *0* in case
> there are 0 input rows
> * The result for *B* supposed to be *0* but since there are no matches by the
> filter it becomes *null*
> * *C* is not touched
> {code}
> # Convert CASE to FILTER without matches
> select sum(case when x = 1 then 1 else 0 end) as a,
> sum(case when x = 1 then 2 else 0 end) as b,
> sum(case when x = 1 then 3 else -1 end) as c
> from (values 0, null, 0, 2) as t(x);
> +---+---++
> | A | B | C |
> +---+---++
> | 0 | 0 | -4 |
> +---+---++
> (1 row)
> !ok
> EnumerableCalc(expr#0..2=[{inputs}], expr#3=[CAST($t0):INTEGER], A=[$t3],
> B=[$t1], C=[$t2])
> EnumerableAggregate(group=[{}], A=[COUNT() FILTER $1], B=[SUM($2) FILTER
> $3], C=[SUM($0)])
> EnumerableCalc(expr#0=[{inputs}], expr#1=[1], expr#2=[=($t0, $t1)],
> expr#3=[3], expr#4=[-1], expr#5=[CASE($t2, $t3, $t4)], expr#6=[IS TRUE($t2)],
> expr#7=[2], $f2=[$t5], $f3=[$t6], $f4=[$t7], $f5=[$t6])
> EnumerableValues(tuples=[[{ 0 }, { null }, { 0 }, { 2 }]])
> !plan
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5950) Default column constraint is erroneously processed.
[
https://issues.apache.org/jira/browse/CALCITE-5950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759152#comment-17759152
]
Julian Hyde commented on CALCITE-5950:
--
I've reviewed. When you've fixed the issues, please get someone else to do a
second review.
> Default column constraint is erroneously processed.
> ---
>
> Key: CALCITE-5950
> URL: https://issues.apache.org/jira/browse/CALCITE-5950
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: pull-request-available
>
> II change table.iq a bit and found a problem with processing default column
> constraint:
> {code:java}
> create table tdef (i int not null, j int default 100);
> (0 rows modified)
> !update
> insert into tdef values (1, DEFAULT);
> (1 row modified)
> !update
> insert into tdef(i) values (2);
> (1 row modified)
> !update
> select * from tdef order by i;
> +---+-+
> | I | J |
> +---+-+
> | 1 | 100 |
> | 2 | 100 |
> +---+-+
> (2 rows)
> !ok
> but obtain from calcite:
> +---+-+
> | I | J |
> +---+-+
> | 1 | |
> | 2 | 100 |
> +---+-+
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759147#comment-17759147
]
Julian Hyde commented on CALCITE-5948:
--
Sounds good.
> Explicit casting should be made if the type of an element in ARRAY/MAP not
> equals with the derived component type
> -
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> First, we need to reach a consensus to allow types of the same family to
> coexist in multiset such as array and map.
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
> LeastRestrictiveType is Integer).In fact, the most of mature engines such as
> spark/hive/flink just also support this behavior. However, this function
> validate success in calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
> {code}
>
> And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw
> exception:
> {code:java}
> java.lang.AssertionError: Expected query to throw exception, but it did not;
> query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must
> be of the same type]
> at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
> at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
> {code}
>
> std ArrayConstructor.
> {code:java}
> public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
> public SqlArrayValueConstructor() {
> super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> getComponentType(
> opBinding.getTypeFactory(),
> opBinding.collectOperandTypes());
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(
> opBinding.getTypeFactory(), type, false);
> }
> } {code}
> std map constructor:
> {code:java}
> public class SqlMapValueConstructor extends SqlMultisetValueConstructor {
> public SqlMapValueConstructor() {
> super("MAP", SqlKind.MAP_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> Pair<@Nullable RelDataType, @Nullable RelDataType> type =
> getComponentTypes(
> opBinding.getTypeFactory(), opBinding.collectOperandTypes());
> --> we need explicit cast here
> return SqlTypeUtil.createMapType(
> opBinding.getTypeFactory(),
> requireNonNull(type.left, "inferred key type"),
> requireNonNull(type.right, "inferred value type"),
> false);
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5923) Some test cases in `SqlOperatorTest` violates the test fixture's design principle
[ https://issues.apache.org/jira/browse/CALCITE-5923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759140#comment-17759140 ] Julian Hyde commented on CALCITE-5923: -- Good point, [~zabetak]. SqlOperatorTest makes it possible to define a lot of tests and run them (at least) twice: once for parsing and validation, and once by generating code in Enumerable convention and executing the functions to check the results. SqlOperatorTest uses the fixture, and other tests may use that same fixture, but only if you add tests to SqlOperatorTest do you get that effect of running the same test in two different environments. Maybe that 'running the test twice' effect could be achieved, in modern junit, using parameterized tests, and maybe we should consider that. But the discusion should recognize the immense effort that has gone into the suite already, and the value it provides, and the difficulty of refactoring it if the only benefit is that we are 'modern'. > Some test cases in `SqlOperatorTest` violates the test fixture's design > principle > - > > Key: CALCITE-5923 > URL: https://issues.apache.org/jira/browse/CALCITE-5923 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Runkang He >Assignee: Runkang He >Priority: Minor > Labels: pull-request-available > > There are some test cases in `SqlOperatorTest` directly use the > `SqlOperatorFixtureImpl.DEFAULT` to get the `SqlOperatorFixture`, including > `SqlOperatorTest.testCast` and many other test cases related with `CAST` > operator. This causes that the result check is missing when execute > `CalciteSqlOperatorTest`, which should has result check. > This violates the design principle introduced by CALCITE-4885, which we > should alway use `SqlOperatorTest.fixture()` to get the `SqlOperatorFixture`. > This principle allows us to override`fixture()` method in subclasses to run > tests in a different environment. > So I think we should fix these related test cases to keep consistent with the > principle. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5955) Non-aggregate window functions incorrectly contain window frame clause for BigQuery
[
https://issues.apache.org/jira/browse/CALCITE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759139#comment-17759139
]
Julian Hyde commented on CALCITE-5955:
--
As I've said before, {{PERCENTILE_CONT}} is an inverse distribution function,
not a window function. BigQuery uses {{OVER}} syntax, but other databases (and
ISO standard SQL) would write something like "SELECT PERCENTILE_CONT(0.5)
WITHIN GROUP (ORDER BY x) ...".
Let's not get confused by BigQuery's syntax. If Calcite has a RelNode tree that
contains a call to PERCENTILE_CONT then of course we should generate BigQuery's
native syntax, which uses OVER. But Calcite should not imagine that it is
dealing with a window function (RexOver, Window).
When you say "you have a query like SELECT PERCENTILE_CONT(x, .5) OVER() ..."
how does that query get into the system? Are you parsing that text? Or are you
creating a RelNode tree similar to that query by making RelBuilder calls?
> Non-aggregate window functions incorrectly contain window frame clause for
> BigQuery
> ---
>
> Key: CALCITE-5955
> URL: https://issues.apache.org/jira/browse/CALCITE-5955
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
>
> Currently if you have a query like:
> {{SELECT PERCENTILE_CONT(x, .5) OVER() FROM x;}} the {{OVER()}} clause gets
> unparsed with a {{window frame clause}} which BigQuery defines
> [here|https://cloud.google.com/bigquery/docs/reference/standard-sql/window-function-calls#def_window_frame].
>
> From the docs: "Only aggregate analytic functions can use a window frame
> clause."
> This causes BigQuery to fail with the following error: {{Window framing
> clause is not allowed for analytic function percentile_cont}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5713) SqlBasicCall's Deep Copy Logic Raises Rule Optimization Exception
[
https://issues.apache.org/jira/browse/CALCITE-5713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759137#comment-17759137
]
Julian Hyde commented on CALCITE-5713:
--
I see that your PR does include a test case. I didn't read the test case
because its name - misleadingly - implied that it was a unit test for
{{SqlBasicCall}}.
This bug does what I keep asking people not to do. It starts from the perceived
solution and works backwards.
Let's start from the problem, which is that we can't plan a particular query.
If the summary was "Query with nested call to QUARTER function throws error
'cannot translate call'", then we would have a better chance of finding a
solution.
Let's try to find a minimal test case. I notice that there are 3 levels of
nested function calls; is there a test case with fewer levels of nesting? I
notice that the functions all use JDBC 'fn' syntax; does the problem reproduce
if you use regular function syntax?
My hypothesis about the root cause is this. Function expansion works either
top-down or bottom-up, and it does so in a way that throws away the expansion
that happens on the arguments to a function. The fix might be to switch from
top-down to bottom-up (or vice versa; I haven't read the code), or to make
multiple passes until expansion reaches a fixed point.
> SqlBasicCall's Deep Copy Logic Raises Rule Optimization Exception
> -
>
> Key: CALCITE-5713
> URL: https://issues.apache.org/jira/browse/CALCITE-5713
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Guoliang Sun
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> h3. Background
> In the fix for
> [CALCITE-4795,|https://issues.apache.org/jira/browse/CALCITE-4795] the
> operands in the SqlBasicCall class were changed from SqlNode[] to
> ImmutableNullableList. Also change the variable name to operandList, and add
> a new set method to modify the elements in the collection.
> h3. Exception
> Take the following SQL as an example
> {code:sql}
> SELECT { fn TRUNCATE(
> { fn QUARTER(
> { fn TIMESTAMPADD(
> SQL_TSI_HOUR,
> 1,
> { ts '1900-01-01 00:00:00' }
> ) }
> ) },
> 0
> ) }
> FROM "TDVT"."CALCS" "CALCS"
> GROUP BY 1.1001
> {code}
> An exception is thrown when the optimization execution reaches the
> CoreRules.PROJECT_REDUCE_EXPRESSIONS rule: {color:#DE350B}cannot translate
> call QUARTER($t4){color}
> h3. RootCause
> The SqlBasicCall#set method uses a deep copy in order to modify immutable
> collections and returns a new operandList object when modified.
> If the SQL contains an operation that requires a rewrite call, such as
> QUARTER in the above SQL, the deep copy logic will cause the operator and
> operandList to be different and eventually raise an exception.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5956) Support parsing non-standard collection types
[
https://issues.apache.org/jira/browse/CALCITE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759131#comment-17759131
]
Julian Hyde commented on CALCITE-5956:
--
Yes it can support it in the core parser, but should it?
> Support parsing non-standard collection types
> -
>
> Key: CALCITE-5956
> URL: https://issues.apache.org/jira/browse/CALCITE-5956
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> Calcite support SQL standard collection types. For example:
> {code:sql}
> INTEGER ARRAY;
> INTEGER ARRAY ARRAY;
> VARCHAR(5) MULTISET;
> INTEGER MULTISET ARRAY;{code}
> Many DBMS support a dialect of {{ARRAY}} and {{MULITSET}},
> I think Calcite can also support this dialect in core Parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5836) Implement Rel2Sql for MERGE
[ https://issues.apache.org/jira/browse/CALCITE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759073#comment-17759073 ] Gregory Hart commented on CALCITE-5836: --- [~hongyuguo], I'd like to revisit this but it probably won't be anytime soon. Feel free to work on this if you'd like. > Implement Rel2Sql for MERGE > --- > > Key: CALCITE-5836 > URL: https://issues.apache.org/jira/browse/CALCITE-5836 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Gregory Hart >Assignee: Gregory Hart >Priority: Major > Labels: pull-request-available > > Add support for MERGE operations in RelToSqlConverter.visit(TableModify). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759018#comment-17759018
]
Ran Tao commented on CALCITE-5948:
--
this issue has changed to "Explicit casting should be made if the type of an
element in ARRAY/MAP not equals with the derived component type", because the
`MapConstructor` has same problem.
> Explicit casting should be made if the type of an element in ARRAY/MAP not
> equals with the derived component type
> -
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> First, we need to reach a consensus to allow types of the same family to
> coexist in multiset such as array and map.
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
> LeastRestrictiveType is Integer).In fact, the most of mature engines such as
> spark/hive/flink just also support this behavior. However, this function
> validate success in calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
> {code}
>
> And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw
> exception:
> {code:java}
> java.lang.AssertionError: Expected query to throw exception, but it did not;
> query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must
> be of the same type]
> at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
> at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
> {code}
>
> std ArrayConstructor.
> {code:java}
> public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
> public SqlArrayValueConstructor() {
> super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> getComponentType(
> opBinding.getTypeFactory(),
> opBinding.collectOperandTypes());
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(
> opBinding.getTypeFactory(), type, false);
> }
> } {code}
> std map constructor:
> {code:java}
> public class SqlMapValueConstructor extends SqlMultisetValueConstructor {
> public SqlMapValueConstructor() {
> super("MAP", SqlKind.MAP_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> Pair<@Nullable RelDataType, @Nullable RelDataType> type =
> getComponentTypes(
> opBinding.getTypeFactory(), opBinding.collectOperandTypes());
> --> we need explicit cast here
> return SqlTypeUtil.createMapType(
> opBinding.getTypeFactory(),
> requireNonNull(type.left, "inferred key type"),
> requireNonNull(type.right, "inferred value type"),
> false);
> }
> }{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Description:
First, we need to reach a consensus to allow types of the same family to
coexist in multiset such as array and map.
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
{code}
And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw
exception:
{code:java}
java.lang.AssertionError: Expected query to throw exception, but it did not;
query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must be
of the same type]
at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)
at
org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
{code}
std ArrayConstructor.
{code:java}
public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
public SqlArrayValueConstructor() {
super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
getComponentType(
opBinding.getTypeFactory(),
opBinding.collectOperandTypes());
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(
opBinding.getTypeFactory(), type, false);
}
} {code}
std map constructor:
{code:java}
public class SqlMapValueConstructor extends SqlMultisetValueConstructor {
public SqlMapValueConstructor() {
super("MAP", SqlKind.MAP_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
Pair<@Nullable RelDataType, @Nullable RelDataType> type =
getComponentTypes(
opBinding.getTypeFactory(), opBinding.collectOperandTypes());
--> we need explicit cast here
return SqlTypeUtil.createMapType(
opBinding.getTypeFactory(),
requireNonNull(type.left, "inferred key type"),
requireNonNull(type.right, "inferred value type"),
false);
}
}{code}
was:
First, we need to reach a consensus to allow types of the same family to
coexist in multiset such as array and map.
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Description:
First, we need to reach a consensus to allow types of the same family to
coexist in multiset such as array and map.
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
{code}
And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw
exception:
{code:java}
java.lang.AssertionError: Expected query to throw exception, but it did not;
query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must be
of the same type]
at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)
at
org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
{code}
std ArrayConstructor.
{code:java}
public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
public SqlArrayValueConstructor() {
super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
getComponentType(
opBinding.getTypeFactory(),
opBinding.collectOperandTypes());
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(
opBinding.getTypeFactory(), type, false);
}
} {code}
std map constructor:
{code:java}
public class SqlMapValueConstructor extends SqlMultisetValueConstructor {
public SqlMapValueConstructor() {
super("MAP", SqlKind.MAP_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
Pair<@Nullable RelDataType, @Nullable RelDataType> type =
getComponentTypes(
opBinding.getTypeFactory(), opBinding.collectOperandTypes());
--> we need explicit cast here
return SqlTypeUtil.createMapType(
opBinding.getTypeFactory(),
requireNonNull(type.left, "inferred key type"),
requireNonNull(type.right, "inferred value type"),
false);
}
}{code}
spark library array
{code:java}
private static RelDataType arrayReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
opBinding.getOperandCount() > 0
? ReturnTypes.LEAST_RESTRICTIVE.inferReturnType(opBinding)
: opBinding.getTypeFactory().createUnknownType();
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(opBinding.getTypeFactory(), type, false);
} {code}
was:
First, we need to reach a consensus to allow types of the same family to
coexist in multiset such as array and map.
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Description:
First, we need to reach a consensus to allow types of the same family to
coexist in multiset such as array and map.
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
{code}
And `{*}map[1, 1, 2, cast(1 as tinyint)]{*}` is correct but calcite throw
exception:
{code:java}
java.lang.AssertionError: Expected query to throw exception, but it did not;
query [values (map[1, 1, 2, cast(1 as tinyint)])]; expected [Parameters must be
of the same type]
at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:240)
at
org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:111)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkQueryFails(SqlOperatorFixtureImpl.java:174)
{code}
e.g. and more array functions failed in runtime when use element cast.
{code:java}
//java.lang.ClassCastException: java.lang.Byte cannot be cast to
java.lang.Integer
select array(1, cast(2 as tinyint))
// java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang.Long
select array_prepend(array[1, cast(2 as bigint)], 3)
select array_prepend(array[1, 2], cast(3 as bigint))
// java.lang.ClassCastException: java.lang.Short cannot be cast to
java.lang.Integer
select array_append(array[1, cast(2 as smallint)], 3)
select array_append(array[1, 2], cast(3 as smallint))
// java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang.Long
select array_reverse(array[1, cast(2 as bigint)])
// java.lang.ClassCastException: java.lang.Short cannot be cast to
java.lang.Integer
array_distinct(array[1, 2, cast(2 as smallint), 1])
more functions failed... {code}
std ArrayConstructor.
{code:java}
public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
public SqlArrayValueConstructor() {
super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
getComponentType(
opBinding.getTypeFactory(),
opBinding.collectOperandTypes());
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(
opBinding.getTypeFactory(), type, false);
}
} {code}
spark library array
{code:java}
private static RelDataType arrayReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
opBinding.getOperandCount() > 0
? ReturnTypes.LEAST_RESTRICTIVE.inferReturnType(opBinding)
: opBinding.getTypeFactory().createUnknownType();
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(opBinding.getTypeFactory(), type, false);
} {code}
was:
First, we need to reach a consensus to allow types of the same family to
coexist in array functions (calcite use SameOperandTypeChecker or
LeastRestrictiveType to support and implement this semantics).
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Summary: Explicit casting should be made if the type of an element in ARRAY
not equals with the derived component type (was: Explicit casting should be
made if the type of an element in ARRAY/MAP not equals with the derived
component type)
> Explicit casting should be made if the type of an element in ARRAY not equals
> with the derived component type
> -
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> First, we need to reach a consensus to allow types of the same family to
> coexist in array functions (calcite use SameOperandTypeChecker or
> LeastRestrictiveType to support and implement this semantics).
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
> LeastRestrictiveType is Integer).In fact, the most of mature engines such as
> spark/hive/flink just also support this behavior. However, this function
> validate success in calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
> {code}
> e.g. and more array functions failed in runtime when use element cast.
> {code:java}
> //java.lang.ClassCastException: java.lang.Byte cannot be cast to
> java.lang.Integer
> select array(1, cast(2 as tinyint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array_prepend(array[1, cast(2 as bigint)], 3)
> select array_prepend(array[1, 2], cast(3 as bigint))
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> select array_append(array[1, cast(2 as smallint)], 3)
> select array_append(array[1, 2], cast(3 as smallint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array_reverse(array[1, cast(2 as bigint)])
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> array_distinct(array[1, 2, cast(2 as smallint), 1])
> more functions failed... {code}
>
> std ArrayConstructor.
> {code:java}
> public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
> public SqlArrayValueConstructor() {
> super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> getComponentType(
> opBinding.getTypeFactory(),
> opBinding.collectOperandTypes());
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(
> opBinding.getTypeFactory(), type, false);
> }
> } {code}
>
> spark library array
> {code:java}
> private static RelDataType arrayReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> opBinding.getOperandCount() > 0
> ? ReturnTypes.LEAST_RESTRICTIVE.inferReturnType(opBinding)
> : opBinding.getTypeFactory().createUnknownType();
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(opBinding.getTypeFactory(), type, false);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Summary: Explicit casting should be made if the type of an element in
ARRAY/MAP not equals with the derived component type (was: Explicit casting
should be made if the type of an element in ARRAY not equals with the derived
component type)
> Explicit casting should be made if the type of an element in ARRAY/MAP not
> equals with the derived component type
> -
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> First, we need to reach a consensus to allow types of the same family to
> coexist in array functions (calcite use SameOperandTypeChecker or
> LeastRestrictiveType to support and implement this semantics).
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
> LeastRestrictiveType is Integer).In fact, the most of mature engines such as
> spark/hive/flink just also support this behavior. However, this function
> validate success in calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
> {code}
> e.g. and more array functions failed in runtime when use element cast.
> {code:java}
> //java.lang.ClassCastException: java.lang.Byte cannot be cast to
> java.lang.Integer
> select array(1, cast(2 as tinyint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array_prepend(array[1, cast(2 as bigint)], 3)
> select array_prepend(array[1, 2], cast(3 as bigint))
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> select array_append(array[1, cast(2 as smallint)], 3)
> select array_append(array[1, 2], cast(3 as smallint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array_reverse(array[1, cast(2 as bigint)])
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> array_distinct(array[1, 2, cast(2 as smallint), 1])
> more functions failed... {code}
>
> std ArrayConstructor.
> {code:java}
> public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
> public SqlArrayValueConstructor() {
> super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> getComponentType(
> opBinding.getTypeFactory(),
> opBinding.collectOperandTypes());
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(
> opBinding.getTypeFactory(), type, false);
> }
> } {code}
>
> spark library array
> {code:java}
> private static RelDataType arrayReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> opBinding.getOperandCount() > 0
> ? ReturnTypes.LEAST_RESTRICTIVE.inferReturnType(opBinding)
> : opBinding.getTypeFactory().createUnknownType();
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(opBinding.getTypeFactory(), type, false);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Description:
First, we need to reach a consensus to allow types of the same family to
coexist in array functions (calcite use SameOperandTypeChecker or
LeastRestrictiveType to support and implement this semantics).
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
{code}
e.g. and more array functions failed in runtime when use element cast.
{code:java}
//java.lang.ClassCastException: java.lang.Byte cannot be cast to
java.lang.Integer
select array(1, cast(2 as tinyint))
// java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang.Long
select array_prepend(array[1, cast(2 as bigint)], 3)
select array_prepend(array[1, 2], cast(3 as bigint))
// java.lang.ClassCastException: java.lang.Short cannot be cast to
java.lang.Integer
select array_append(array[1, cast(2 as smallint)], 3)
select array_append(array[1, 2], cast(3 as smallint))
// java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang.Long
select array_reverse(array[1, cast(2 as bigint)])
// java.lang.ClassCastException: java.lang.Short cannot be cast to
java.lang.Integer
array_distinct(array[1, 2, cast(2 as smallint), 1])
more functions failed... {code}
std ArrayConstructor.
{code:java}
public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
public SqlArrayValueConstructor() {
super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
getComponentType(
opBinding.getTypeFactory(),
opBinding.collectOperandTypes());
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(
opBinding.getTypeFactory(), type, false);
}
} {code}
spark library array
{code:java}
private static RelDataType arrayReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
opBinding.getOperandCount() > 0
? ReturnTypes.LEAST_RESTRICTIVE.inferReturnType(opBinding)
: opBinding.getTypeFactory().createUnknownType();
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(opBinding.getTypeFactory(), type, false);
} {code}
was:
First, we need to reach a consensus to allow types of the same family to
coexist in array functions (calcite use SameOperandTypeChecker or
LeastRestrictiveType to support and implement this semantics).
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Component/s: core
(was: avatica)
> Explicit casting should be made if the type of an element in ARRAY not equals
> with the derived component type
> -
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> First, we need to reach a consensus to allow types of the same family to
> coexist in array functions (calcite use SameOperandTypeChecker or
> LeastRestrictiveType to support and implement this semantics).
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
> LeastRestrictiveType is Integer).In fact, the most of mature engines such as
> spark/hive/flink just also support this behavior. However, this function
> validate success in calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
> {code}
> e.g. and more array functions failed in runtime when use element cast.
> {code:java}
> //java.lang.ClassCastException: java.lang.Byte cannot be cast to
> java.lang.Integer
> select array(1, cast(2 as tinyint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array_prepend(array[1, cast(2 as bigint)], 3)
> select array_prepend(array[1, 2], cast(3 as bigint))
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> select array_append(array[1, cast(2 as smallint)], 3)
> select array_append(array[1, 2], cast(3 as smallint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array_reverse(array[1, cast(2 as bigint)])
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> array_distinct(array[1, 2, cast(2 as smallint), 1])
> more functions failed... {code}
>
> std ArrayConstructor.
> {code:java}
> public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
> public SqlArrayValueConstructor() {
> super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> getComponentType(
> opBinding.getTypeFactory(),
> opBinding.collectOperandTypes());
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(
> opBinding.getTypeFactory(), type, false);
> }
> } {code}
>
> spark library array
> {code:java}
> private static RelDataType arrayReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> opBinding.getOperandCount() > 0
> ? ReturnTypes.LEAST_RESTRICTIVE.inferReturnType(opBinding)
> : opBinding.getTypeFactory().createUnknownType();
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(opBinding.getTypeFactory(), type, false);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY/MAP not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Summary: Explicit casting should be made if the type of an element in
ARRAY/MAP not equals with the derived component type (was: Explicit casting
should be made if the type of an element in ARRAY not equals with the derived
component type)
> Explicit casting should be made if the type of an element in ARRAY/MAP not
> equals with the derived component type
> -
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> First, we need to reach a consensus to allow types of the same family to
> coexist in array functions (calcite use SameOperandTypeChecker or
> LeastRestrictiveType to support and implement this semantics).
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
> LeastRestrictiveType is Integer).In fact, the most of mature engines such as
> spark/hive/flink just also support this behavior. However, this function
> validate success in calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
> {code}
> e.g. and more array functions failed in runtime when use element cast.
> {code:java}
> //java.lang.ClassCastException: java.lang.Byte cannot be cast to
> java.lang.Integer
> select array(1, cast(2 as tinyint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array_prepend(array[1, cast(2 as bigint)], 3)
> select array_prepend(array[1, 2], cast(3 as bigint))
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> select array_append(array[1, cast(2 as smallint)], 3)
> select array_append(array[1, 2], cast(3 as smallint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array_reverse(array[1, cast(2 as bigint)])
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> array_distinct(array[1, 2, cast(2 as smallint), 1])
> more functions failed... {code}
>
> std ArrayConstructor.
> {code:java}
> public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
> public SqlArrayValueConstructor() {
> super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
> }
> @Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> getComponentType(
> opBinding.getTypeFactory(),
> opBinding.collectOperandTypes());
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(
> opBinding.getTypeFactory(), type, false);
> }
> } {code}
>
> spark library array
> {code:java}
> private static RelDataType arrayReturnType(SqlOperatorBinding opBinding) {
> RelDataType type =
> opBinding.getOperandCount() > 0
> ? ReturnTypes.LEAST_RESTRICTIVE.inferReturnType(opBinding)
> : opBinding.getTypeFactory().createUnknownType();
> --> we need explicit cast here
> requireNonNull(type, "inferred array element type");
> return SqlTypeUtil.createArrayType(opBinding.getTypeFactory(), type, false);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Description:
First, we need to reach a consensus to allow types of the same family to
coexist in array functions (calcite use SameOperandTypeChecker or
LeastRestrictiveType to support and implement this semantics).
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
at
org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
at
org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
{code}
e.g. and more array functions failed in runtime when use element cast.
{code:java}
//java.lang.ClassCastException: java.lang.Byte cannot be cast to
java.lang.Integer
select array(1, cast(2 as tinyint))
// java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang.Long
select array_prepend(array[1, cast(2 as bigint)], 3)
select array_prepend(array[1, 2], cast(3 as bigint))
// java.lang.ClassCastException: java.lang.Short cannot be cast to
java.lang.Integer
select array_append(array[1, cast(2 as smallint)], 3)
select array_append(array[1, 2], cast(3 as smallint))
// java.lang.ClassCastException: java.lang.Integer cannot be cast to
java.lang.Long
select array_reverse(array[1, cast(2 as bigint)])
// java.lang.ClassCastException: java.lang.Short cannot be cast to
java.lang.Integer
array_distinct(array[1, 2, cast(2 as smallint), 1])
more functions failed... {code}
std ArrayConstructor.
{code:java}
public class SqlArrayValueConstructor extends SqlMultisetValueConstructor {
public SqlArrayValueConstructor() {
super("ARRAY", SqlKind.ARRAY_VALUE_CONSTRUCTOR);
}
@Override public RelDataType inferReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
getComponentType(
opBinding.getTypeFactory(),
opBinding.collectOperandTypes());
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(
opBinding.getTypeFactory(), type, false);
}
} {code}
spark library array
{code:java}
private static RelDataType arrayReturnType(SqlOperatorBinding opBinding) {
RelDataType type =
opBinding.getOperandCount() > 0
? ReturnTypes.LEAST_RESTRICTIVE.inferReturnType(opBinding)
: opBinding.getTypeFactory().createUnknownType();
--> we need explicit cast here
requireNonNull(type, "inferred array element type");
return SqlTypeUtil.createArrayType(opBinding.getTypeFactory(), type, false);
} {code}
was:
First, we need to reach a consensus to allow types of the same family to
coexist in array functions (calcite use SameOperandTypeChecker or
LeastRestrictiveType to support and implement this semantics).
It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
LeastRestrictiveType is Integer).In fact, the most of mature engines such as
spark/hive/flink just also support this behavior. However, this function
validate success in calcite but it failed in runtime, exception stack is:
{code:java}
java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
java.lang.Integer
at
org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
at
org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
at
[jira] [Updated] (CALCITE-5948) Explicit casting should be made if the type of an element in ARRAY not equals with the derived component type
[
https://issues.apache.org/jira/browse/CALCITE-5948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-5948:
-
Summary: Explicit casting should be made if the type of an element in ARRAY
not equals with the derived component type (was: A serials of array functions
failed in runtime cause by incorrect avatica type cast behavior )
> Explicit casting should be made if the type of an element in ARRAY not equals
> with the derived component type
> -
>
> Key: CALCITE-5948
> URL: https://issues.apache.org/jira/browse/CALCITE-5948
> Project: Calcite
> Issue Type: Bug
> Components: avatica
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
>
> First, we need to reach a consensus to allow types of the same family to
> coexist in array functions (calcite use SameOperandTypeChecker or
> LeastRestrictiveType to support and implement this semantics).
> It means the form like `{*}array(1, cast(2 as tinyint)){*}` is correct(the
> LeastRestrictiveType is Integer).In fact, the most of mature engines such as
> spark/hive/flink just also support this behavior. However, this function
> validate success in calcite but it failed in runtime, exception stack is:
> {code:java}
> java.lang.ClassCastException: class java.lang.Byte cannot be cast to class
> java.lang.Integer
> at
> org.apache.calcite.avatica.util.AbstractCursor$IntAccessor.getInt(AbstractCursor.java:522)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.convertValue(AbstractCursor.java:1396)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getObject(AbstractCursor.java:1377)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getArray(AbstractCursor.java:1432)
> at
> org.apache.calcite.avatica.util.AbstractCursor$ArrayAccessor.getString(AbstractCursor.java:1444)
> at
> org.apache.calcite.avatica.AvaticaResultSet.getString(AvaticaResultSet.java:241)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:112)
> at org.apache.calcite.util.JdbcTypeImpl$10.get(JdbcTypeImpl.java:109)
> at
> org.apache.calcite.sql.test.ResultCheckers.compareResultSetWithMatcher(ResultCheckers.java:248)
> at
> org.apache.calcite.sql.test.ResultCheckers$MatcherResultChecker.checkResult(ResultCheckers
> {code}
> e.g. and more array functions failed in runtime when use element cast.
> {code:java}
> //java.lang.ClassCastException: java.lang.Byte cannot be cast to
> java.lang.Integer
> select array(1, cast(2 as tinyint))
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> select array(1, cast(2 as smallint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array(1, cast(2 as bigint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array_prepend(array[1, cast(2 as bigint)], 3)
> select array_prepend(array[1, 2], cast(3 as bigint))
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> select array_append(array[1, cast(2 as smallint)], 3)
> select array_append(array[1, 2], cast(3 as smallint))
> // java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long
> select array_reverse(array[1, cast(2 as bigint)])
> // java.lang.ClassCastException: java.lang.Short cannot be cast to
> java.lang.Integer
> array_distinct(array[1, 2, cast(2 as smallint), 1])
> more functions failed... {code}
>
> the error code path(a part of them):
> {code:java}
> private static class IntAccessor extends ExactNumericAccessor {
> private IntAccessor(Getter getter) {
> super(getter);
> }
> public int getInt() throws SQLException {
> Integer o = (Integer) super.getObject(); --> error logic
> return o == null ? 0 : o;
> }
> public long getLong() throws SQLException {
> return getInt();
> }
> }{code}
> we may should fix it in calcite-avatica. and add more test cases to cover it
> in calcite-main.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5956) Support parsing non-standard collection types
[
https://issues.apache.org/jira/browse/CALCITE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-5956:
Summary: Support parsing non-standard collection types (was: Support
parsing non-standand collection types)
> Support parsing non-standard collection types
> -
>
> Key: CALCITE-5956
> URL: https://issues.apache.org/jira/browse/CALCITE-5956
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> Calcite support SQL standard collection types. For example:
> {code:sql}
> INTEGER ARRAY;
> INTEGER ARRAY ARRAY;
> VARCHAR(5) MULTISET;
> INTEGER MULTISET ARRAY;{code}
> Many DBMS support a dialect of {{ARRAY}} and {{MULITSET}},
> I think Calcite can also support this dialect in core Parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5956) Support parsing non-standand collection types
[
https://issues.apache.org/jira/browse/CALCITE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-5956:
Description:
Calcite support SQL standard collection types. For example:
{code:sql}
INTEGER ARRAY;
INTEGER ARRAY ARRAY;
VARCHAR(5) MULTISET;
INTEGER MULTISET ARRAY;{code}
Many DBMS support a dialect of {{ARRAY}} and {{MULITSET}},
I think Calcite can also support this dialect in core Parser.
was:
Calcite support SQL standard collection types. For example:
{code:sql}
INTEGER ARRAY;
INTEGER ARRAY ARRAY;
VARCHAR(5) MULTISET;
INTEGER MULTISET ARRAY;{code}
Many DBMS support a dialect of {{ARRAY}} or {{MULITSET}},
I think Calcite can also support this dialect in core Parser.
> Support parsing non-standand collection types
> -
>
> Key: CALCITE-5956
> URL: https://issues.apache.org/jira/browse/CALCITE-5956
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> Calcite support SQL standard collection types. For example:
> {code:sql}
> INTEGER ARRAY;
> INTEGER ARRAY ARRAY;
> VARCHAR(5) MULTISET;
> INTEGER MULTISET ARRAY;{code}
> Many DBMS support a dialect of {{ARRAY}} and {{MULITSET}},
> I think Calcite can also support this dialect in core Parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5956) Support parsing non-standand collection types
[
https://issues.apache.org/jira/browse/CALCITE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-5956:
Summary: Support parsing non-standand collection types (was: Support
parsing non-standand collection type)
> Support parsing non-standand collection types
> -
>
> Key: CALCITE-5956
> URL: https://issues.apache.org/jira/browse/CALCITE-5956
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> Calcite support SQL standard collection types, for example
> {code:java}
> INTEGER ARRAY;
> INTEGER ARRAY ARRAY;
> VARCHAR(5) MULTISET;
> INTEGER MULTISET ARRAY;{code}
> Many DBMS support a dialect of {{ARRAY}} or {{MULITSET}}
> I think Calcite can also support this dialect in core Parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5956) Support parsing non-standand collection types
[
https://issues.apache.org/jira/browse/CALCITE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-5956:
Description:
Calcite support SQL standard collection types, for example
{code:sql}
INTEGER ARRAY;
INTEGER ARRAY ARRAY;
VARCHAR(5) MULTISET;
INTEGER MULTISET ARRAY;{code}
Many DBMS support a dialect of {{ARRAY}} or {{MULITSET}}
I think Calcite can also support this dialect in core Parser.
was:
Calcite support SQL standard collection types, for example
{code:java}
INTEGER ARRAY;
INTEGER ARRAY ARRAY;
VARCHAR(5) MULTISET;
INTEGER MULTISET ARRAY;{code}
Many DBMS support a dialect of {{ARRAY}} or {{MULITSET}}
I think Calcite can also support this dialect in core Parser.
> Support parsing non-standand collection types
> -
>
> Key: CALCITE-5956
> URL: https://issues.apache.org/jira/browse/CALCITE-5956
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> Calcite support SQL standard collection types, for example
> {code:sql}
> INTEGER ARRAY;
> INTEGER ARRAY ARRAY;
> VARCHAR(5) MULTISET;
> INTEGER MULTISET ARRAY;{code}
> Many DBMS support a dialect of {{ARRAY}} or {{MULITSET}}
> I think Calcite can also support this dialect in core Parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5956) Support parsing non-standand collection types
[
https://issues.apache.org/jira/browse/CALCITE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-5956:
Description:
Calcite support SQL standard collection types. For example:
{code:sql}
INTEGER ARRAY;
INTEGER ARRAY ARRAY;
VARCHAR(5) MULTISET;
INTEGER MULTISET ARRAY;{code}
Many DBMS support a dialect of {{ARRAY}} or {{MULITSET}},
I think Calcite can also support this dialect in core Parser.
was:
Calcite support SQL standard collection types, for example
{code:sql}
INTEGER ARRAY;
INTEGER ARRAY ARRAY;
VARCHAR(5) MULTISET;
INTEGER MULTISET ARRAY;{code}
Many DBMS support a dialect of {{ARRAY}} or {{MULITSET}}
I think Calcite can also support this dialect in core Parser.
> Support parsing non-standand collection types
> -
>
> Key: CALCITE-5956
> URL: https://issues.apache.org/jira/browse/CALCITE-5956
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> Calcite support SQL standard collection types. For example:
> {code:sql}
> INTEGER ARRAY;
> INTEGER ARRAY ARRAY;
> VARCHAR(5) MULTISET;
> INTEGER MULTISET ARRAY;{code}
> Many DBMS support a dialect of {{ARRAY}} or {{MULITSET}},
> I think Calcite can also support this dialect in core Parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5949) RexExecutable correct handling of invalid constant expressions
[
https://issues.apache.org/jira/browse/CALCITE-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759012#comment-17759012
]
Benchao Li commented on CALCITE-5949:
-
How about "RexExecutable should return unchanged original expressions when it
fails"? I went through the PR, it looks good.
> RexExecutable correct handling of invalid constant expressions
> --
>
> Key: CALCITE-5949
> URL: https://issues.apache.org/jira/browse/CALCITE-5949
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Claude Brisson
>Priority: Major
> Labels: pull-request-available
>
> While reducing, when encountering an invalid expression in the list of
> constant expressions, RexExecutor is meant to return all initial expressions
> unchanged.
> It fails to do so, because already handled correct expressions have already
> been added to the returned list, which can be greater than the input list.
> For instance, when given the list \{ LN(2), LN(-2) }, the RexExecutor will
> output a list of length 3.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5956) Support parsing non-standand collection type
[
https://issues.apache.org/jira/browse/CALCITE-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
hongyu guo updated CALCITE-5956:
Description:
Calcite support SQL standard collection types, for example
{code:java}
INTEGER ARRAY;
INTEGER ARRAY ARRAY;
VARCHAR(5) MULTISET;
INTEGER MULTISET ARRAY;{code}
Many DBMS support a dialect of {{ARRAY}} or {{MULITSET}}
I think Calcite can also support this dialect in core Parser.
was:
Calcite support SQL standard collection type, for example
{code:java}
INTEGER ARRAY;
INTEGER ARRAY ARRAY;
VARCHAR(5) MULTISET;
INTEGER MULTISET ARRAY;{code}
A lots of DBMS support a dialect `ARRAY` or `MULITSET`
I think Calcite also can support this dialect in Parser.
> Support parsing non-standand collection type
>
>
> Key: CALCITE-5956
> URL: https://issues.apache.org/jira/browse/CALCITE-5956
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Major
> Fix For: 1.36.0
>
>
> Calcite support SQL standard collection types, for example
> {code:java}
> INTEGER ARRAY;
> INTEGER ARRAY ARRAY;
> VARCHAR(5) MULTISET;
> INTEGER MULTISET ARRAY;{code}
> Many DBMS support a dialect of {{ARRAY}} or {{MULITSET}}
> I think Calcite can also support this dialect in core Parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-5956) Support parsing non-standand collection type
hongyu guo created CALCITE-5956:
---
Summary: Support parsing non-standand collection type
Key: CALCITE-5956
URL: https://issues.apache.org/jira/browse/CALCITE-5956
Project: Calcite
Issue Type: New Feature
Components: core
Affects Versions: 1.35.0
Reporter: hongyu guo
Assignee: hongyu guo
Fix For: 1.36.0
Calcite support SQL standard collection type, for example
{code:java}
INTEGER ARRAY;
INTEGER ARRAY ARRAY;
VARCHAR(5) MULTISET;
INTEGER MULTISET ARRAY;{code}
A lots of DBMS support a dialect `ARRAY` or `MULITSET`
I think Calcite also can support this dialect in Parser.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5922) The SQL generated for the POSITION function(with 3 input arguments) by the SparkSqlDialect is not recognized by Spark SQL
[
https://issues.apache.org/jira/browse/CALCITE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17759009#comment-17759009
]
Jiajun Xie commented on CALCITE-5922:
-
Fixed in
[730361b|https://github.com/apache/calcite/commit/730361b66442e5d12448e120e8ce67fc070b271a].
[~hongyuguo] , Thanks for you PR.
[~nobigo] , Thanks for your review.
> The SQL generated for the POSITION function(with 3 input arguments) by the
> SparkSqlDialect is not recognized by Spark SQL
> -
>
> Key: CALCITE-5922
> URL: https://issues.apache.org/jira/browse/CALCITE-5922
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> In SparkSQL, POSITION(substr, str[, pos]) function only accept
> comma-separated when there are 3 arguments.
> For example:
> {code:java}
> // SparkSQL accepted SQL
> select POSITION('a', 'abc', 1);{code}
> Calcite will use the IN and FROM keyword to separate the input arguments when
> unparsing.
> {code:java}
> // Calcite accepted and unparsed SQL
> select POSITION('a' IN 'abc' FROM 1){code}
> For 2 augument inputs, SparkSQL accept both syntaxes. So I think we should
> write a rule in SparkSqlDialect to convert keyword-separated syntax to
> comma-separted syntax for POSITION function.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-5922) The SQL generated for the POSITION function(with 3 input arguments) by the SparkSqlDialect is not recognized by Spark SQL
[
https://issues.apache.org/jira/browse/CALCITE-5922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiajun Xie resolved CALCITE-5922.
-
Resolution: Fixed
> The SQL generated for the POSITION function(with 3 input arguments) by the
> SparkSqlDialect is not recognized by Spark SQL
> -
>
> Key: CALCITE-5922
> URL: https://issues.apache.org/jira/browse/CALCITE-5922
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: hongyu guo
>Assignee: hongyu guo
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> In SparkSQL, POSITION(substr, str[, pos]) function only accept
> comma-separated when there are 3 arguments.
> For example:
> {code:java}
> // SparkSQL accepted SQL
> select POSITION('a', 'abc', 1);{code}
> Calcite will use the IN and FROM keyword to separate the input arguments when
> unparsing.
> {code:java}
> // Calcite accepted and unparsed SQL
> select POSITION('a' IN 'abc' FROM 1){code}
> For 2 augument inputs, SparkSQL accept both syntaxes. So I think we should
> write a rule in SparkSqlDialect to convert keyword-separated syntax to
> comma-separted syntax for POSITION function.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5836) Implement Rel2Sql for MERGE
[ https://issues.apache.org/jira/browse/CALCITE-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758987#comment-17758987 ] hongyu guo commented on CALCITE-5836: - Hi [~freastro], I noticed that CALCITE-985 has been fixed. Do you have any plans to continue working on this issue? > Implement Rel2Sql for MERGE > --- > > Key: CALCITE-5836 > URL: https://issues.apache.org/jira/browse/CALCITE-5836 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Gregory Hart >Assignee: Gregory Hart >Priority: Major > Labels: pull-request-available > > Add support for MERGE operations in RelToSqlConverter.visit(TableModify). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CALCITE-5615) Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter
[
https://issues.apache.org/jira/browse/CALCITE-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis resolved CALCITE-5615.
--
Resolution: Fixed
Fixed in
https://github.com/apache/calcite/commit/996692e36a0d1bdff2b3fd1e08fa99fcc755f2ab.
Thanks for huge amount of work that you put into this ticket [~mbudiu] and
[~julianhyde] and of course for building up the
https://github.com/hydromatic/sql-logic-test repo!
> Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter
>
>
> Key: CALCITE-5615
> URL: https://issues.apache.org/jira/browse/CALCITE-5615
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Add support for running [Sql Logic Test
> suite|https://github.com/hydromatic/sql-logic-test] using Calcite's HSQLDB
> JDBC adapter. This essentially improves test coverage for the JDBC adapter
> with HSQLDB in particular.
> Running the whole suite is pretty slow (more than 6h) so by default we run
> only one test file (namely
> [select1.test|https://github.com/hydromatic/sql-logic-test/blob/0a809c530457bf0e56d637ef19fcaabd2964fd67/src/main/resources/test/select1.test]).
> The rest of the tests can be run manually by removing the {{@Disabled}}
> annotation.
> Adding more test files and making this part of regular CI runs will be done
> in follow-up tickets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5615) Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter
[
https://issues.apache.org/jira/browse/CALCITE-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stamatis Zampetakis updated CALCITE-5615:
-
Description:
Add support for running [Sql Logic Test
suite|https://github.com/hydromatic/sql-logic-test] using Calcite's HSQLDB JDBC
adapter. This essentially improves test coverage for the JDBC adapter with
HSQLDB in particular.
Running the whole suite is pretty slow (more than 6h) so by default we run only
one test file (namely
[select1.test|https://github.com/hydromatic/sql-logic-test/blob/0a809c530457bf0e56d637ef19fcaabd2964fd67/src/main/resources/test/select1.test]).
The rest of the tests can be run manually by removing the {{@Disabled}}
annotation.
Adding more test files and making this part of regular CI runs will be done in
follow-up tickets.
was:
Sqllogictest is a program designed to verify that an SQL database engine
computes correct results by comparing the results to identical queries from
other SQL database engines.
https://www.sqlite.org/sqllogictest/doc/trunk/about.wiki
The nice thing about SLT is that it contains more than 7 million tests. The
tests only cover the core of SQL, ideally the portable part across all engines.
They only test integers, doubles, and strings. So they could probably be part
of the Calcite slow tests.
The tests should be structured so that any query execution engine can be used.
I plan to contribute such an implementation if people think it is useful, but I
haven't yet worked out all the details.
> Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter
>
>
> Key: CALCITE-5615
> URL: https://issues.apache.org/jira/browse/CALCITE-5615
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.34.0, 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Add support for running [Sql Logic Test
> suite|https://github.com/hydromatic/sql-logic-test] using Calcite's HSQLDB
> JDBC adapter. This essentially improves test coverage for the JDBC adapter
> with HSQLDB in particular.
> Running the whole suite is pretty slow (more than 6h) so by default we run
> only one test file (namely
> [select1.test|https://github.com/hydromatic/sql-logic-test/blob/0a809c530457bf0e56d637ef19fcaabd2964fd67/src/main/resources/test/select1.test]).
> The rest of the tests can be run manually by removing the {{@Disabled}}
> annotation.
> Adding more test files and making this part of regular CI runs will be done
> in follow-up tickets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5615) Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter
[ https://issues.apache.org/jira/browse/CALCITE-5615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stamatis Zampetakis updated CALCITE-5615: - Summary: Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter (was: Run SQLLogicTests using Calcite) > Run SQL Logic Test suite using Calcite's HSQLDB JDBC adapter > > > Key: CALCITE-5615 > URL: https://issues.apache.org/jira/browse/CALCITE-5615 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.34.0, 1.35.0 >Reporter: Mihai Budiu >Assignee: Mihai Budiu >Priority: Minor > Labels: pull-request-available > Fix For: 1.36.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sqllogictest is a program designed to verify that an SQL database engine > computes correct results by comparing the results to identical queries from > other SQL database engines. > https://www.sqlite.org/sqllogictest/doc/trunk/about.wiki > The nice thing about SLT is that it contains more than 7 million tests. The > tests only cover the core of SQL, ideally the portable part across all > engines. They only test integers, doubles, and strings. So they could > probably be part of the Calcite slow tests. > The tests should be structured so that any query execution engine can be used. > I plan to contribute such an implementation if people think it is useful, but > I haven't yet worked out all the details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
