Those queries, and the ones in the 5127 test case, look valid to me.
If "books" is an array then your first query is requesting an array of
arrays. If that's not what you want, you should probably use UNNEST.
On Tue, May 3, 2022 at 5:40 AM Dmitry Sysolyatin
wrote:
>
> I found more failing
I found more failing queries but they are not related to unnest. But looks
like the cause of both https://issues.apache.org/jira/browse/CALCITE-5127 and
those queries is wrong correlate variable's row type. But I am not sure
100%, need an expert :)
!use bookstore
SELECT array(SELECT lau."books")
I have created jira task -
https://issues.apache.org/jira/browse/CALCITE-5127
And also created a commit with test cases -
https://github.com/apache/calcite/commit/27e68ded2c3bea7d7af73dd1dc156e46fb3591a8
On Mon, May 2, 2022 at 6:47 PM Julian Hyde wrote:
> Oops, I misspoke. Calcite hasn’t used
Oops, I misspoke. Calcite hasn’t used the array-to-Values transformation here.
I’m not sure where the ARRAY literal has gone. Possibly it’s still present,
just not being printed in the plan.
Julian
> On May 2, 2022, at 8:41 AM, Julian Hyde wrote:
>
> The plan isn’t “completely wrong”.
The plan isn’t “completely wrong”. Calcite intentionally converts UNNEST of a
constant ARRAY into Values because the latter is a primitive relational
expression.
As for the casts, maybe some confusion about scalar types versus record types
with a single field. Can you please log a jira case.
Hi!
I am working on https://issues.apache.org/jira/browse/CALCITE-5126. When I
was writing tests for this task I faced with issue that reproducible in
main branch as well.
I tried to execute the following query using unnest.iq file
SELECT ARRAY(SELECT * FROM UNNEST(s.x) y)
FROM (SELECT
