You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Alessandro Solimando (Jira)" <ji...@apache.org> on 2020/10/15 20:25:00 UTC
[jira] [Comment Edited] (CALCITE-4293) cassandra adapter returns
null when selecting non-null tuple elements
[ https://issues.apache.org/jira/browse/CALCITE-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214982#comment-17214982 ]
Alessandro Solimando edited comment on CALCITE-4293 at 10/15/20, 8:24 PM:
--------------------------------------------------------------------------
As suggested I have checked in Postgres, it's indeed forbidden to try to access a Record by index.
The following query:
{noformat}
select "T"."X"[1] from (VALUES (ROW(ROW(1,2), ROW(4, 8)))) as "T"("X")
{noformat}
Gives this error:
{noformat}
ERROR: cannot subscript type record because it is not an array SQL state: 42804{noformat}
All this looks like well [documented|https://www.postgresql.org/docs/9.1/sql-expressions.html] (Section 4.2.3. Subscripts), and it conforms to the SQL standard, as per Stamatis' first reply, so it all adds up fine.
As Julian suggested, in principle it should not be possible to apply `ITEM` to a Struct, so the query mentioned in the ticket description should fail. However, at [SqlItemOperator#96|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L96] we can see that we support access via a "String"-typed argument when `ITEM` is applied to a Struct/Row (same goes for the rest, the type checker accepts to apply `ITEM` on `ANY` type etc., with the notable exception of the “getAllowedSignatures” method, which is outdated).
See also [SqlValidatorTest.java#L11933,|https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/test/SqlValidatorTest.java#L11933] which uses the ITEM operator over a Struct.
Now the remaining question is: do we want to support positional access for “anonymous” struct types too?
IMO this extension is in line with the partial support for applying ITEM to Struct types with no particular drawbacks, and it’s less surprising than the existing partial support we have right now (I got fooled by that when writing the unit tests for Cassandra, for instance, since the type system was not complaining I assumed it was OK).
If this makes sense to you as well, I propose to open a new ticket and keep discussing there for those who are interested.
was (Author: asolimando):
As suggested I have checked in Postgres, it's indeed forbidden to try to access a Record by index.
The following query:
{noformat}
select "T"."X"[1] from (VALUES (ROW(ROW(1,2), ROW(4, 8)))) as "T"("X")
{noformat}
Gives this error:
{noformat}
ERROR: cannot subscript type record because it is not an array SQL state: 42804{noformat}
All this looks like well [documented|https://www.postgresql.org/docs/9.1/sql-expressions.html] (Section 4.2.3. Subscripts), and it conforms to the SQL standard, as per Stamatis' first reply, so it all adds up fine.
As Julian suggested, in principle it should not be possible to apply `ITEM` to a Struct, so the query mentioned in the ticket description should fail. However, at [SqlItemOperator#96|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/fun/SqlItemOperator.java#L96] we can see that we support access via a "String"-typed argument when `ITEM` is applied to a Struct/Row (same goes for the rest, the type checker accepts to apply `ITEM` on `ANY` type etc., with the notable exception of the “getAllowedSignatures” method, which is outdated).
See also [SqlValidatorTest.java#L11933,|https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/test/SqlValidatorTest.java#L11933] which uses the ITEM operator over a Struct.
Now the remaining question is: do we want to support positional access for “anonymous” struct types too?
IMO this extension is in line with the partial support for applying ITEM to Struct types with no particular drawbacks, and it’s less surprising than the existing partial support we have right now (I got fooled by that when writing the unit tests for Cassandra, for instance, since the type system was not complaining I assumed it was OK).
If this makes sense to you as well, I propose to open a new ticket and keep discussing there for those who are interested.
> cassandra adapter returns null when selecting non-null tuple elements
> ---------------------------------------------------------------------
>
> Key: CALCITE-4293
> URL: https://issues.apache.org/jira/browse/CALCITE-4293
> Project: Calcite
> Issue Type: Bug
> Components: cassandra-adapter
> Affects Versions: 1.25.0
> Reporter: Alessandro Solimando
> Assignee: Alessandro Solimando
> Priority: Major
>
> The following test currently fails due to the _EXPR$i_ elements are null and don't match their actual value within the _f_tuple_ field:
> {code:java}
> @Test void testTupleInnerValues() {
> CalciteAssert.that()
> .with(DTCASSANDRA)
> .query("select x['1'], x['2'], x['3'] from "
> + "(select \"f_tuple\" from \"test_collections\") as T(x)")
> .returns("EXPR$0=3000000000"
> + "; EXPR$1=30ff87"
> + "; EXPR$2=2015-05-03 13:30:54\n");
> }{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)