[jira] [Commented] (CALCITE-6301) Extend ‘Must-filter’ columns to support a conditional bypass list
[ https://issues.apache.org/jira/browse/CALCITE-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823890#comment-17823890 ] Alessandro Solimando commented on CALCITE-6301: --- Isn't this equivalent to say that "EMPNAME" is an alternative to the "Must-filter-fields"? In that case I think it's simpler to extend the syntax to provide multiple "Must-filter-fields" lists, something like "[EMPNO, DEPTNO],[ENAME]" (a list of lists, conceptually, where each list is an independent alternative). >From your example it's not clear if multiple by-pass fields values would >require to be there at the same time (very much like "Must-filter-fields"), or >if any of them alone would do. For instance, for Bypass-fields: [ENAME, EMPNO], would the following queries be valid or not? SELECT * FROM EMP WHERE ENAME = ’name’ SELECT * FROM EMP WHERE EMPNO = 1 In any case, the multiple "Must-filter-fields" syntax would allow to express both pretty naturally. You can even probably re-use the same machinery you coded for "Must-filter-fields" more easily. WDYT? > Extend ‘Must-filter’ columns to support a conditional bypass list > - > > Key: CALCITE-6301 > URL: https://issues.apache.org/jira/browse/CALCITE-6301 > Project: Calcite > Issue Type: Improvement >Reporter: Oliver Lee >Assignee: Oliver Lee >Priority: Major > > In [CALCITE-6219] we introduced SemanticTable, where tables that implement > this interface can define fields to be ‘must-filter’, and a query without > those filters in any of its WHERE or HAVING clauses, it will throw a > validation error. > > I would like to extend this functionality to support a by-pass list of fields > such that if any field from this secondary list is present in a WHERE / > HAVING clause, then the must-filter fields can be ignored and will not raise > an exception if not filtered on. > > Ex. > > EMP table specifies the following: > Must-filter-fields: [EMPNO, DEPTNO] > Bypass-fields: [ENAME] > > > SELECT * FROM EMP WHERE EMPNO = 1 and DEPTNO = 2 -> No error > SELECT * FROM EMP WHERE EMPNO = 1 -> Error > SELECT * FROM EMP WHERE EMPNO = 1 and ENAME = ’name’ -> No error > SELECT * FROM EMP WHERE ENAME = ’name’ -> No error > > > > Again, special considerations are for handling > > * Joins > * CTEs > * Subqueries > > > And a similar exhaustive suite of tests like the one for [CALCITE-6219] > should be employed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6301) Extend ‘Must-filter’ columns to support a conditional bypass list
[ https://issues.apache.org/jira/browse/CALCITE-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823890#comment-17823890 ] Alessandro Solimando edited comment on CALCITE-6301 at 3/6/24 7:42 AM: --- Isn't this equivalent to say that "ENAME" is an alternative to the "Must-filter-fields"? In that case I think it's simpler to extend the syntax to provide multiple "Must-filter-fields" lists, something like "[EMPNO, DEPTNO],[ENAME]" (a list of lists, conceptually, where each list is an independent alternative). >From your example it's not clear if multiple by-pass fields values would >require to be there at the same time (very much like "Must-filter-fields"), or >if any of them alone would do. For instance, for Bypass-fields: [ENAME, EMPNO], would the following queries be valid or not? SELECT * FROM EMP WHERE ENAME = ’name’ SELECT * FROM EMP WHERE EMPNO = 1 In any case, the multiple "Must-filter-fields" syntax would allow to express both pretty naturally. You can even probably re-use the same machinery you coded for "Must-filter-fields" more easily. WDYT? was (Author: asolimando): Isn't this equivalent to say that "EMPNAME" is an alternative to the "Must-filter-fields"? In that case I think it's simpler to extend the syntax to provide multiple "Must-filter-fields" lists, something like "[EMPNO, DEPTNO],[ENAME]" (a list of lists, conceptually, where each list is an independent alternative). >From your example it's not clear if multiple by-pass fields values would >require to be there at the same time (very much like "Must-filter-fields"), or >if any of them alone would do. For instance, for Bypass-fields: [ENAME, EMPNO], would the following queries be valid or not? SELECT * FROM EMP WHERE ENAME = ’name’ SELECT * FROM EMP WHERE EMPNO = 1 In any case, the multiple "Must-filter-fields" syntax would allow to express both pretty naturally. You can even probably re-use the same machinery you coded for "Must-filter-fields" more easily. WDYT? > Extend ‘Must-filter’ columns to support a conditional bypass list > - > > Key: CALCITE-6301 > URL: https://issues.apache.org/jira/browse/CALCITE-6301 > Project: Calcite > Issue Type: Improvement >Reporter: Oliver Lee >Assignee: Oliver Lee >Priority: Major > > In [CALCITE-6219] we introduced SemanticTable, where tables that implement > this interface can define fields to be ‘must-filter’, and a query without > those filters in any of its WHERE or HAVING clauses, it will throw a > validation error. > > I would like to extend this functionality to support a by-pass list of fields > such that if any field from this secondary list is present in a WHERE / > HAVING clause, then the must-filter fields can be ignored and will not raise > an exception if not filtered on. > > Ex. > > EMP table specifies the following: > Must-filter-fields: [EMPNO, DEPTNO] > Bypass-fields: [ENAME] > > > SELECT * FROM EMP WHERE EMPNO = 1 and DEPTNO = 2 -> No error > SELECT * FROM EMP WHERE EMPNO = 1 -> Error > SELECT * FROM EMP WHERE EMPNO = 1 and ENAME = ’name’ -> No error > SELECT * FROM EMP WHERE ENAME = ’name’ -> No error > > > > Again, special considerations are for handling > > * Joins > * CTEs > * Subqueries > > > And a similar exhaustive suite of tests like the one for [CALCITE-6219] > should be employed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CALCITE-6301) Extend ‘Must-filter’ columns to support a conditional bypass list
Oliver Lee created CALCITE-6301: --- Summary: Extend ‘Must-filter’ columns to support a conditional bypass list Key: CALCITE-6301 URL: https://issues.apache.org/jira/browse/CALCITE-6301 Project: Calcite Issue Type: Improvement Reporter: Oliver Lee Assignee: Oliver Lee In [CALCITE-6219] we introduced SemanticTable, where tables that implement this interface can define fields to be ‘must-filter’, and a query without those filters in any of its WHERE or HAVING clauses, it will throw a validation error. I would like to extend this functionality to support a by-pass list of fields such that if any field from this secondary list is present in a WHERE / HAVING clause, then the must-filter fields can be ignored and will not raise an exception if not filtered on. Ex. EMP table specifies the following: Must-filter-fields: [EMPNO, DEPTNO] Bypass-fields: [ENAME] SELECT * FROM EMP WHERE EMPNO = 1 and DEPTNO = 2 -> No error SELECT * FROM EMP WHERE EMPNO = 1 -> Error SELECT * FROM EMP WHERE EMPNO = 1 and ENAME = ’name’ -> No error SELECT * FROM EMP WHERE ENAME = ’name’ -> No error Again, special considerations are for handling * Joins * CTEs * Subqueries And a similar exhaustive suite of tests like the one for [CALCITE-6219] should be employed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CALCITE-6219) 'Must-filter' columns
[
https://issues.apache.org/jira/browse/CALCITE-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lee updated CALCITE-6219:
Summary: 'Must-filter' columns (was: Support SQL Validation for Tables
with columns tagged as 'filter required')
> 'Must-filter' columns
> -
>
> Key: CALCITE-6219
> URL: https://issues.apache.org/jira/browse/CALCITE-6219
> Project: Calcite
> Issue Type: New Feature
>Reporter: Oliver Lee
>Assignee: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> Suppose that a user's Table definitions come in with a tag on certain columns
> that indicates the the column is required to have a filter on it for all
> incoming queries.
>
> I would like to add support to validate that incoming queries satisfies the
> table condition.
> If all of the table's specified fields has a filter on it (present in a WHERE
> or HAVING clause for the query), then it will not error.
>
> ex.
> {{EMP}} table specifies that {{EMPNO}} requires a filter
>
> {{select * from emp where empno = 1}} -> No error
> {{select * from emp where ename = 'bob' -> Error}}
> {{select * from emp -> Error}}
>
> The validation would occur after the namespace validation in
> {{SqlValidatorImpl}} as a separate pass.
>
> I am envisioning that the full filter validation algorithm will form a couple
> of key steps
> * Scanning the catalog/schema/tables and determining which fields are
> tagged to always require filters
> * A pass through the SQL statement to see if a certain field needs to be
> filtered multiple times (potentially for CTE, joins? needs further
> investigation)
> * A pass through the SQL statement to discover filters on the statement
>
> In determining whether a {{WHERE}} or {{HAVING}} clause contains a certain
> field identifier, there will need to be a helper visitor for WHERE or HAVING
> SqlNodes to collect all of the SqlIdentifiers that could be nested within the
> {{operandList}}
>
> Special considerations:
> * joins
> * CTEs
> * subqueries
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5607) Datetime MINUS throws ArrayIndexOutOfBounds error when serializing toRex
[
https://issues.apache.org/jira/browse/CALCITE-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823813#comment-17823813
]
Oliver Lee commented on CALCITE-5607:
-
[~Sergey Nuyanzin] ,
I've updated the commit messages and made a new commit here:
[https://github.com/apache/calcite/pull/3715]
Do you want to drop the previous commit and merge this one? Or can you do some
reshuffling to maintain the ordering?
> Datetime MINUS throws ArrayIndexOutOfBounds error when serializing toRex
>
>
> Key: CALCITE-5607
> URL: https://issues.apache.org/jira/browse/CALCITE-5607
> Project: Calcite
> Issue Type: Improvement
>Reporter: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We found a bug in {{RelJson#toRex}} for the {{TIMESTAMP_DIFF}} call for Big
> Query dialect.
> {{TIMESTAMP_DIFF}} is translated to the {{MINUS_DATE}}
> [operator|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L2113-L2116]
> with a return type explicitly declared as the interval.
> {{MINUS_DATE}} uses an
> {{[ARG2_NULLABLE|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L241]}}
> return type inference which requires 3 operands. This is fine in most cases
> where the RexCall is then used to generate SQL or for native implementations.
> However, in {{{}RelJson#toRex{}}}, when it tries to reconstruct the entire
> call to a RexNode, it attempts to derive the return type of the
> {{MINUS_DATE}} operator using the {{ARG2_NULLABLE}} inference. This throws an
> error as there are only 2 operands given to the {{MINUS_DATE}} operator.
>
> The solution here is to do something similar to how we handle {{CAST}} and to
> add in "type" when serializing to JSON in {{RelJson.toJson(RexNode node)}}
> for {{SqlKind.MINUS}} so that
> {{[jsonType|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L712]}}
> will be defined in {{{}toRex{}}}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5607) Datetime MINUS throws ArrayIndexOutOfBounds error when serializing toRex
[
https://issues.apache.org/jira/browse/CALCITE-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Lee updated CALCITE-5607:
Summary: Datetime MINUS throws ArrayIndexOutOfBounds error when serializing
toRex (was: Error when deserializing TIMESTAMP_DIFF in RelJson#toJson)
> Datetime MINUS throws ArrayIndexOutOfBounds error when serializing toRex
>
>
> Key: CALCITE-5607
> URL: https://issues.apache.org/jira/browse/CALCITE-5607
> Project: Calcite
> Issue Type: Improvement
>Reporter: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We found a bug in {{RelJson#toRex}} for the {{TIMESTAMP_DIFF}} call for Big
> Query dialect.
> {{TIMESTAMP_DIFF}} is translated to the {{MINUS_DATE}}
> [operator|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L2113-L2116]
> with a return type explicitly declared as the interval.
> {{MINUS_DATE}} uses an
> {{[ARG2_NULLABLE|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L241]}}
> return type inference which requires 3 operands. This is fine in most cases
> where the RexCall is then used to generate SQL or for native implementations.
> However, in {{{}RelJson#toRex{}}}, when it tries to reconstruct the entire
> call to a RexNode, it attempts to derive the return type of the
> {{MINUS_DATE}} operator using the {{ARG2_NULLABLE}} inference. This throws an
> error as there are only 2 operands given to the {{MINUS_DATE}} operator.
>
> The solution here is to do something similar to how we handle {{CAST}} and to
> add in "type" when serializing to JSON in {{RelJson.toJson(RexNode node)}}
> for {{SqlKind.MINUS}} so that
> {{[jsonType|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L712]}}
> will be defined in {{{}toRex{}}}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6248) Illegal dates are accepted by casts
[
https://issues.apache.org/jira/browse/CALCITE-6248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823772#comment-17823772
]
Julian Hyde commented on CALCITE-6248:
--
Postel's law applies: "be conservative in what you send, be liberal in what you
accept". If we are sending a date, we need to use ISO-8601 format. But if we
are receiving a date in a cast, we should accept anything reasonable. Certainly
I think leading zeros (or missing leading zeros) are harmless.
> Illegal dates are accepted by casts
> ---
>
> Key: CALCITE-6248
> URL: https://issues.apache.org/jira/browse/CALCITE-6248
> Project: Calcite
> Issue Type: Bug
> Components: avatica, core
>Affects Versions: 1.36.0
>Reporter: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following test passes in SqlOperatorTest:
> {code:java}
> @Test public void testIllegalDate() {
> final SqlOperatorFixture f = fixture();
> f.checkScalar("cast('1945-02-32' as DATE)",
> "1945-03-04", "DATE NOT NULL");
> }
> {code}
> There is no February 32, I suspect that this expression should produce an
> error.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6284) Invalid conversion triggers ClassCastException
[
https://issues.apache.org/jira/browse/CALCITE-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823770#comment-17823770
]
Julian Hyde commented on CALCITE-6284:
--
Can you fill out the description? Describe what's going on (and going wrong) in
the test case.
> Invalid conversion triggers ClassCastException
> --
>
> Key: CALCITE-6284
> URL: https://issues.apache.org/jira/browse/CALCITE-6284
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Tim Nieradzik
>Priority: Major
>
> Test case:
> {code:java}
> @Test void bindStringParameter() {
> for (SqlTypeName tpe : SqlTypeName.INT_TYPES) {
> final String sql =
> "with cte as (select cast(100 as " + tpe.getName() + ") as empid)"
> + "select * from cte where empid = ?";
> CalciteAssert.hr()
> .query(sql)
> .consumesPreparedStatement(p -> {
> p.setString(1, "100");
> })
> .returnsUnordered("EMPID=100");
> }
> } {code}
> This throws a {{ClassCastException}} which should be a more user-friendly
> message.
> Discussion: [https://github.com/apache/calcite/pull/3687]}}{}}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6239) Add a PostGIS dialect that supports ST_ functions
[ https://issues.apache.org/jira/browse/CALCITE-6239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823753#comment-17823753 ] Julian Hyde commented on CALCITE-6239: -- [~bchapuis], In my [6239-postgis-dialect|https://github.com/julianhyde/calcite/tree/6239-postgis-dialect] branch I have added a commit that attempts to decouple the GEOMETRY type from the JTS Geometry class. Please take a look. > Add a PostGIS dialect that supports ST_ functions > - > > Key: CALCITE-6239 > URL: https://issues.apache.org/jira/browse/CALCITE-6239 > Project: Calcite > Issue Type: New Feature > Components: core, spatial >Reporter: Bertil Chapuis >Assignee: Bertil Chapuis >Priority: Minor > Labels: pull-request-available > > Calcite implements support for spatial types (geometry, point, etc.) and > spatial functions (ST_), and it can connect to PostGIS via a JdbcSchema. > However, the Postgresql dialect does not currently handle spatial types and > functions. As a result, Calcite tries to execute the spatial functions at the > level of the JVM instead of pushing them down to postgis. > As a result, the following query gets executed, but the type of the geom > column is incorrect: > SELECT id, geom FROM public.spatial_table > The following query fails with a ClassCastException as Calcite tries to use > the java implementation of the ST_SRID function: > SELECT id, ST_SRID(geom) FROM public.spatial_table > java.lang.ClassCastException: class org.postgresql.util.PGobject cannot be > cast to class org.locationtech.jts.geom.Geometry > (org.postgresql.util.PGobject and org.locationtech.jts.geom.Geometry are in > unnamed module of loader 'app') > In my current understanding, this issue could be addressed with a new > PostgisSqlDialect that extends PostgresqlSqlDialect and adds support for > spatial types and functions. Here is a tentative roadmap: > - Add all the spatial functions to the SqlKind class > - Create a PostgisSqlDialect class that extends PostgresqlSqlDialect > - Add support for the spatial types (geometry) by overriding the getCastSpec > method of the SqlDialect class > - Add support for the spatial functions by overriding the supportsFunction > method of the SqlDialect class > - Add support for the spatial aggregate functions by overriding the > supportsAggregateFunction method of the SqlDialect class -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6292) Support more arrow type
[
https://issues.apache.org/jira/browse/CALCITE-6292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823745#comment-17823745
]
Julian Hyde commented on CALCITE-6292:
--
Arrow types are very similar to SQL and JDBC types. You should create a good
mapping between the types, and do most of the reasoning in the SQL domain.
> Support more arrow type
> ---
>
> Key: CALCITE-6292
> URL: https://issues.apache.org/jira/browse/CALCITE-6292
> Project: Calcite
> Issue Type: Sub-task
>Reporter: hongyu guo
>Priority: Major
>
> All arrow type:
> {code:java}
> public static enum ArrowTypeID {
> Null(Type.Null),
> Struct(Type.Struct_),
> List(Type.List),
> LargeList(Type.LargeList),
> FixedSizeList(Type.FixedSizeList),
> Union(Type.Union),
> Map(Type.Map),
> Int(Type.Int),
> FloatingPoint(Type.FloatingPoint),
> Utf8(Type.Utf8),
> LargeUtf8(Type.LargeUtf8),
> Binary(Type.Binary),
> LargeBinary(Type.LargeBinary),
> FixedSizeBinary(Type.FixedSizeBinary),
> Bool(Type.Bool),
> Decimal(Type.Decimal),
> Date(Type.Date),
> Time(Type.Time),
> Timestamp(Type.Timestamp),
> Interval(Type.Interval),
> Duration(Type.Duration),
> NONE(Type.NONE);
> }
> {code}
> we support now:
> {code:java}
> public static ArrowFieldType of(ArrowType arrowType) {
> switch (arrowType.getTypeID()) {
> case Int:
> int bitWidth = ((ArrowType.Int) arrowType).getBitWidth();
> switch (bitWidth) {
> case 64:
> return LONG;
> case 32:
> return INT;
> case 16:
> return SHORT;
> case 8:
> return BYTE;
> default:
> throw new IllegalArgumentException("Unsupported Int bit width: " +
> bitWidth);
> }
> case Bool:
> return BOOLEAN;
> case Utf8:
> return STRING;
> case FloatingPoint:
> FloatingPointPrecision precision = ((ArrowType.FloatingPoint)
> arrowType).getPrecision();
> switch (precision) {
> case SINGLE:
> return FLOAT;
> case DOUBLE:
> return DOUBLE;
> default:
> throw new IllegalArgumentException("Unsupported Floating point
> precision: " + precision);
> }
> case Date:
> return DATE;
> case Decimal:
> return DECIMAL;
> default:
> throw new IllegalArgumentException("Unsupported type: " + arrowType);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6293) Support OR condition in arrow adapter
[
https://issues.apache.org/jira/browse/CALCITE-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823744#comment-17823744
]
Julian Hyde commented on CALCITE-6293:
--
Can you provide more details?
This case (and others you have logged recently) may make sense for your
organization's planning, but does not provide enough details to know what
feature you intend to build. OR is already trivially supported by queries on
the Arrow adapter - all the data comes out of Arrow and is filtered in
EnumerableCalc or whatever - but if you intend to do something better you
should give details.
> Support OR condition in arrow adapter
> -
>
> Key: CALCITE-6293
> URL: https://issues.apache.org/jira/browse/CALCITE-6293
> Project: Calcite
> Issue Type: Sub-task
>Reporter: hongyu guo
>Priority: Major
>
> for example
> {code:java}
> String sql = "select \"intField\", \"stringField\"\n"
> + "from arrowdata\n"
> + "where \"intField\"=12 or \"stringField\"='12'"; {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6290) Incorrect return type for BigQuery TRUNC
[
https://issues.apache.org/jira/browse/CALCITE-6290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary resolved CALCITE-6290.
---
Fix Version/s: 1.37.0
Resolution: Fixed
Merged via
[8c1ec07|https://github.com/apache/calcite/commit/8c1ec07ebc483799cfdf4f21552db0908981e0e4],
thanks for the review, [~julianhyde]!
> Incorrect return type for BigQuery TRUNC
>
>
> Key: CALCITE-6290
> URL: https://issues.apache.org/jira/browse/CALCITE-6290
> Project: Calcite
> Issue Type: Bug
>Reporter: Tanner Clary
>Assignee: Tanner Clary
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The [BigQuery
> docs|https://cloud.google.com/bigquery/docs/reference/standard-sql/mathematical_functions#trunc]
> state that when the TRUNC function is provided an integer argument, it
> should return a double. However, we currently have the return type set to
> {{ARG0_NULLABLE}}. We should probably adjust this to
> {{ARG0_EXCEPT_INTEGER_NULLABLE}} similar to CALCITE-5747
> This change also adjusts the NULLABILITY for CEIL_BIG_QUERY and
> FLOOR_BIG_QUERY as I incorrectly set these with I implemented CALCITE-5747
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CALCITE-6224) Add LOG2 function (enabled in Mysql, Spark library)
[
https://issues.apache.org/jira/browse/CALCITE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Nuyanzin reassigned CALCITE-6224:
Assignee: Caican Cai
> Add LOG2 function (enabled in Mysql, Spark library)
> ---
>
> Key: CALCITE-6224
> URL: https://issues.apache.org/jira/browse/CALCITE-6224
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Assignee: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The log2 function is supported in many databases, such as spark, mysql,
> postgres, etc.
> {code:java}
> > SELECT log2(2);
> 1.0 {code}
> links：
> [https://spark.apache.org/docs/3.4.0/api/sql/index.html#log2]
> https://dev.mysql.com/doc/refman/8.0/en/mathematical-functions.html#function_log2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6224) Add LOG2 function (enabled in Mysql, Spark library)
[
https://issues.apache.org/jira/browse/CALCITE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823684#comment-17823684
]
Tanner Clary commented on CALCITE-6224:
---
[~Sergey Nuyanzin] Yeah sorry about that I left the comment and forgot to
resolve it haha.
> Add LOG2 function (enabled in Mysql, Spark library)
> ---
>
> Key: CALCITE-6224
> URL: https://issues.apache.org/jira/browse/CALCITE-6224
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The log2 function is supported in many databases, such as spark, mysql,
> postgres, etc.
> {code:java}
> > SELECT log2(2);
> 1.0 {code}
> links：
> [https://spark.apache.org/docs/3.4.0/api/sql/index.html#log2]
> https://dev.mysql.com/doc/refman/8.0/en/mathematical-functions.html#function_log2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CALCITE-6224) Add LOG2 function (enabled in Mysql, Spark library)
[
https://issues.apache.org/jira/browse/CALCITE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanner Clary resolved CALCITE-6224.
---
Resolution: Fixed
> Add LOG2 function (enabled in Mysql, Spark library)
> ---
>
> Key: CALCITE-6224
> URL: https://issues.apache.org/jira/browse/CALCITE-6224
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The log2 function is supported in many databases, such as spark, mysql,
> postgres, etc.
> {code:java}
> > SELECT log2(2);
> 1.0 {code}
> links：
> [https://spark.apache.org/docs/3.4.0/api/sql/index.html#log2]
> https://dev.mysql.com/doc/refman/8.0/en/mathematical-functions.html#function_log2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5607) Error when deserializing TIMESTAMP_DIFF in RelJson#toJson
[
https://issues.apache.org/jira/browse/CALCITE-5607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823652#comment-17823652
]
Sergey Nuyanzin commented on CALCITE-5607:
--
[~oliverlee] may be I missed something, can you please point to the PR/commit
fixing the last requested things or do you have time to fix it in case there is
no such?
I'm asking since we are about to prepare for the next release and it would be
great to include it there as well
> Error when deserializing TIMESTAMP_DIFF in RelJson#toJson
> -
>
> Key: CALCITE-5607
> URL: https://issues.apache.org/jira/browse/CALCITE-5607
> Project: Calcite
> Issue Type: Improvement
>Reporter: Oliver Lee
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We found a bug in {{RelJson#toRex}} for the {{TIMESTAMP_DIFF}} call for Big
> Query dialect.
> {{TIMESTAMP_DIFF}} is translated to the {{MINUS_DATE}}
> [operator|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql2rel/StandardConvertletTable.java#L2113-L2116]
> with a return type explicitly declared as the interval.
> {{MINUS_DATE}} uses an
> {{[ARG2_NULLABLE|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/sql/type/ReturnTypes.java#L241]}}
> return type inference which requires 3 operands. This is fine in most cases
> where the RexCall is then used to generate SQL or for native implementations.
> However, in {{{}RelJson#toRex{}}}, when it tries to reconstruct the entire
> call to a RexNode, it attempts to derive the return type of the
> {{MINUS_DATE}} operator using the {{ARG2_NULLABLE}} inference. This throws an
> error as there are only 2 operands given to the {{MINUS_DATE}} operator.
>
> The solution here is to do something similar to how we handle {{CAST}} and to
> add in "type" when serializing to JSON in {{RelJson.toJson(RexNode node)}}
> for {{SqlKind.MINUS}} so that
> {{[jsonType|https://github.com/apache/calcite/blob/c28d1dcbc34e748b7bea9712ef6bcf43793a91e8/core/src/main/java/org/apache/calcite/rel/externalize/RelJson.java#L712]}}
> will be defined in {{{}toRex{}}}.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6224) Add LOG2 function (enabled in Mysql, Spark library)
[
https://issues.apache.org/jira/browse/CALCITE-6224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823567#comment-17823567
]
Sergey Nuyanzin commented on CALCITE-6224:
--
[~tanclary] since you've merged it, am I right that we can resolve this issue
and mark it as Fixed?
> Add LOG2 function (enabled in Mysql, Spark library)
> ---
>
> Key: CALCITE-6224
> URL: https://issues.apache.org/jira/browse/CALCITE-6224
> Project: Calcite
> Issue Type: New Feature
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.37.0
>
>
> The log2 function is supported in many databases, such as spark, mysql,
> postgres, etc.
> {code:java}
> > SELECT log2(2);
> 1.0 {code}
> links：
> [https://spark.apache.org/docs/3.4.0/api/sql/index.html#log2]
> https://dev.mysql.com/doc/refman/8.0/en/mathematical-functions.html#function_log2
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6266) SqlValidatorException with LATERAL TABLE and JOIN
[
https://issues.apache.org/jira/browse/CALCITE-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823558#comment-17823558
]
Jeyhun Karimov commented on CALCITE-6266:
-
Hi [~julianhyde] do you have any other hints/suggestions/comments about the
issue/PR? Thanks
> SqlValidatorException with LATERAL TABLE and JOIN
> -
>
> Key: CALCITE-6266
> URL: https://issues.apache.org/jira/browse/CALCITE-6266
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.31.0, 1.32.0, 1.33.0, 1.34.0, 1.35.0, 1.36.0
>Reporter: Jeyhun Karimov
>Priority: Critical
> Labels: pull-request-available
>
> I have the following test in SqlValidatorTest.java
> {code:java}
> @Test void test() {
> sql("select * from dept, lateral table(ramp(deptno)) CROSS JOIN (VALUES
> ('A'), ('B'))")
> .ok();
> }
> {code}
> This test passes on Calcite {{calcite-1.29.0}} and {{calcite-1.30.0}} but
> fails on other releases, including the main branch
> (c774c313a81d01c4e3e77cf296d04839c5ab04c0). The exception is:
> {code:java}
> org.opentest4j.AssertionFailedError: Validator threw unexpected exception;
> query [select * from dept, lateral table(ramp(deptno)) CROSS JOIN (VALUES
> ('A'), ('B'))]; exception [Column 'DEPTNO' not found in any table]; class
> [class org.apache.calcite.sql.validate.SqlValidatorException]; pos [line 1
> col 40 thru line 1 col 40]
> at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:38)
> at org.junit.jupiter.api.Assertions.fail(Assertions.java:135)
> at org.apache.calcite.sql.test.SqlTests.checkEx(SqlTests.java:352)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.assertExceptionIsThrown(AbstractSqlTester.java:112)
> at
> org.apache.calcite.test.SqlValidatorFixture.ok(SqlValidatorFixture.java:191)
> at
> org.apache.calcite.test.SqlValidatorTest.jey2(SqlValidatorTest.java:284)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
> at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
> at
>
[jira] [Updated] (CALCITE-6300) Function map_values gives exception when inserted element type not equals map component type
[
https://issues.apache.org/jira/browse/CALCITE-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caican Cai updated CALCITE-6300:
Summary: Function map_values gives exception when inserted element type not
equals map component type (was: Function map_values gives exception when
inserted element type not equals array component type)
> Function map_values gives exception when inserted element type not equals map
> component type
>
>
> Key: CALCITE-6300
> URL: https://issues.apache.org/jira/browse/CALCITE-6300
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Assignee: Caican Cai
>Priority: Major
> Fix For: 1.37.0
>
>
> If we run the expression below in calcite, it will cause exception:
> {code:java}
> map_values(map('foo', cast (2 as tinyint), 'bar', 2)) {code}
> {code:java}
> java.lang.ClassCastException: java.lang.Byte cannot be cast to
> 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.java:321)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:14300)
> at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160) at
> org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:226)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:450)
>at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:225)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:229)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapValuesFunc(SqlOperatorTest.java:7276)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
>at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
>at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
>at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
>at
>
[jira] [Commented] (CALCITE-6300) Function map_values gives exception when inserted element type not equals array component type
[
https://issues.apache.org/jira/browse/CALCITE-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823489#comment-17823489
]
Caican Cai commented on CALCITE-6300:
-
I will fix it
> Function map_values gives exception when inserted element type not equals
> array component type
> --
>
> Key: CALCITE-6300
> URL: https://issues.apache.org/jira/browse/CALCITE-6300
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Priority: Major
> Fix For: 1.37.0
>
>
> If we run the expression below in calcite, it will cause exception:
> {code:java}
> map_values(map('foo', cast (2 as tinyint), 'bar', 2)) {code}
> {code:java}
> java.lang.ClassCastException: java.lang.Byte cannot be cast to
> 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.java:321)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:14300)
> at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160) at
> org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:226)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:450)
>at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:225)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:229)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapValuesFunc(SqlOperatorTest.java:7276)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
>at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
>at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
>at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
>at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
>
[jira] [Assigned] (CALCITE-6300) Function map_values gives exception when inserted element type not equals array component type
[
https://issues.apache.org/jira/browse/CALCITE-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caican Cai reassigned CALCITE-6300:
---
Assignee: Caican Cai
> Function map_values gives exception when inserted element type not equals
> array component type
> --
>
> Key: CALCITE-6300
> URL: https://issues.apache.org/jira/browse/CALCITE-6300
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.36.0
>Reporter: Caican Cai
>Assignee: Caican Cai
>Priority: Major
> Fix For: 1.37.0
>
>
> If we run the expression below in calcite, it will cause exception:
> {code:java}
> map_values(map('foo', cast (2 as tinyint), 'bar', 2)) {code}
> {code:java}
> java.lang.ClassCastException: java.lang.Byte cannot be cast to
> 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.java:321)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:14300)
> at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160) at
> org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:226)
> at
> org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:450)
>at
> org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:225)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:229)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapValuesFunc(SqlOperatorTest.java:7276)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
>at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
>at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
>at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
>at
> org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
>
[jira] [Created] (CALCITE-6300) Function map_values gives exception when inserted element type not equals array component type
Caican Cai created CALCITE-6300:
---
Summary: Function map_values gives exception when inserted element
type not equals array component type
Key: CALCITE-6300
URL: https://issues.apache.org/jira/browse/CALCITE-6300
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.36.0
Reporter: Caican Cai
Fix For: 1.37.0
If we run the expression below in calcite, it will cause exception:
{code:java}
map_values(map('foo', cast (2 as tinyint), 'bar', 2)) {code}
{code:java}
java.lang.ClassCastException: java.lang.Byte cannot be cast to 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.java:321)
at
org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:14300)
at org.apache.calcite.sql.test.SqlTester.check(SqlTester.java:160) at
org.apache.calcite.test.SqlOperatorFixtureImpl.lambda$checkScalar$2(SqlOperatorFixtureImpl.java:226)
at
org.apache.calcite.sql.test.AbstractSqlTester.forEachQuery(AbstractSqlTester.java:450)
at
org.apache.calcite.test.SqlOperatorFixtureImpl.checkScalar(SqlOperatorFixtureImpl.java:225)
at
org.apache.calcite.sql.test.SqlOperatorFixture.checkScalar(SqlOperatorFixture.java:229)
at
org.apache.calcite.test.SqlOperatorTest.testMapValuesFunc(SqlOperatorTest.java:7276)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at
