[
https://issues.apache.org/jira/browse/CALCITE-4293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17214982#comment-17214982
]
Alessandro Solimando commented on CALCITE-4293:
-----------------------------------------------
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)
