[jira] [Resolved] (CALCITE-6030) DATE_PART is not handled by the RexToLixTranslator
[
https://issues.apache.org/jira/browse/CALCITE-6030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benchao Li resolved CALCITE-6030.
-
Resolution: Fixed
Fixed via
https://github.com/apache/calcite/commit/e3b5028223d82e2432d037d56d2cee1315a6d7ab
[~mbudiu] Thanks for your contribution!
> DATE_PART is not handled by the RexToLixTranslator
> --
>
> Key: CALCITE-6030
> URL: https://issues.apache.org/jira/browse/CALCITE-6030
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> The following test, when added to SqlOperatorTest, causes a RuntimeException:
> {code:java}
> @Test void testDatePart() {
> final SqlOperatorFixture f = fixture().withLibrary(SqlLibrary.POSTGRESQL)
> .withParserConfig(p ->
> p.withParserFactory(SqlBabelParserImpl.FACTORY));
> f.checkScalar("DATE_PART(second, TIME '10:10:10')",
> "10", "BIGINT NOT NULL");
> }
> {code}
> Note that this needs https://github.com/apache/calcite/pull/3445 to execute
> correctly.
> The stack trace is:
> {code:java}
> Suppressed: java.lang.RuntimeException: cannot translate call DATE_PART($t1,
> $t2)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:1160)
> at
> org.apache.calcite.adapter.enumerable.RexToLixTranslator.visitCall(RexToLixTranslator.java:101)
> at org.apache.calcite.rex.RexCall.accept(RexCall.java:189)
> {code}
> According to the documentation DATE_PART is just an alias for EXTRACT, which
> is (mostly) implemented, so this should work.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1346#comment-1346
]
Ran Tao edited comment on CALCITE-6041 at 10/20/23 2:08 AM:
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters to support this 'array()' form rather
than support orderby or limit). It accept all exprs.
and there is no test case, and even the correctness is problematic. we need
another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno desc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
select array(select empno from emps order by empno asc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
{code}
the orderby will not work.
So what I want to illustrate here is that calcite parser originally does not
support orderby/limit for array/map/multiset sub-query.
was (Author: lemonjing):
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters to support this 'array()' form rather
than support orderby or limit). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno desc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
select array(select empno from emps order by empno asc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
{code}
the orderby will not work.
So what I want to illustrate here is that calcite parser originally does not
support orderby/limit for array/map/multiset sub-query.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1519#comment-1519
]
Ran Tao commented on CALCITE-6061:
--
thank you all. I'm ok with this. then i will close this ticket.
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time.
> {code:java}
> +-+
> | EXPR$0 |
> +-+
> | {1=2, 3=4, 5=6} |
> +-+
> {code}
> because calcite use LinkedHashMap for storage. But semantically, the order
> should not be guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +++
> | op | EXPR$0 |
> +++
> | +I | {5=6, 1=2, 3=4} |
> +++
> Received a total of 1 row {code}
> it will return different order when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao closed CALCITE-6061.
Resolution: Not A Bug
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time.
> {code:java}
> +-+
> | EXPR$0 |
> +-+
> | {1=2, 3=4, 5=6} |
> +-+
> {code}
> because calcite use LinkedHashMap for storage. But semantically, the order
> should not be guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +++
> | op | EXPR$0 |
> +++
> | +I | {5=6, 1=2, 3=4} |
> +++
> Received a total of 1 row {code}
> it will return different order when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6062) Allow conversion of un-zoned timestamp strings to timestamp with local time zone
[
https://issues.apache.org/jira/browse/CALCITE-6062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble updated CALCITE-6062:
Description:
[This
function|https://github.com/apache/calcite/blob/ce88348960e95e1c13da850b4422b2f49f022d93/core/src/main/java/org/apache/calcite/runtime/SqlFunctions.java#L4333]
that implements conversion from strings to {{TIMESTAMP WITH LOCAL TIME ZONE}}
uses {{TimestampWithTimeZoneString}}, which seems to have been a subtle mistake.
That function is only used to implement {{CAST}} expressions from strings to TS
w/ LTZ. Those expressions should allow for strings that do not have a time
zone, e.g. {{CAST('2023-10-19 12:00:00' AS TIMESTAMP WITH LOCAL TIME ZONE)}},
but it currently cannot because the {{TimestampWithTimeZoneString}} class
always expects a string with a time zone on the end.
In the case that no zone is included in the string, we should assume that the
string expresses a timestamp in the data context time zone by default.
was:
[This
function|https://github.com/apache/calcite/blob/ce88348960e95e1c13da850b4422b2f49f022d93/core/src/main/java/org/apache/calcite/runtime/SqlFunctions.java#L4333]
that implements conversion from strings to {{TIMESTAMP WITH LOCAL TIME ZONE}}
uses {{TimestampWithTimeZoneString}}, which seems to have been a subtle mistake.
That function is only used to implement {{CAST}} expressions from strings to TS
w/ LTZ. Those expressions should allow for strings that do not have a time
zone, e.g. {{CAST('2023-10-19 12:00:00' AS TIMESTAMP WITH LOCAL TIME ZONE)}},
but it currently cannot because the {{TimestampWithTimeZoneString}} class
always expects a time zone string.
In the case that no zone is included in the string, we should assume that the
string expresses a timestamp in the data context time zone by defaul.
> Allow conversion of un-zoned timestamp strings to timestamp with local time
> zone
>
>
> Key: CALCITE-6062
> URL: https://issues.apache.org/jira/browse/CALCITE-6062
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Will Noble
>Priority: Minor
>
> [This
> function|https://github.com/apache/calcite/blob/ce88348960e95e1c13da850b4422b2f49f022d93/core/src/main/java/org/apache/calcite/runtime/SqlFunctions.java#L4333]
> that implements conversion from strings to {{TIMESTAMP WITH LOCAL TIME
> ZONE}} uses {{TimestampWithTimeZoneString}}, which seems to have been a
> subtle mistake.
> That function is only used to implement {{CAST}} expressions from strings to
> TS w/ LTZ. Those expressions should allow for strings that do not have a time
> zone, e.g. {{CAST('2023-10-19 12:00:00' AS TIMESTAMP WITH LOCAL TIME ZONE)}},
> but it currently cannot because the {{TimestampWithTimeZoneString}} class
> always expects a string with a time zone on the end.
> In the case that no zone is included in the string, we should assume that the
> string expresses a timestamp in the data context time zone by default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6062) Allow conversion of un-zoned timestamp strings to timestamp with local time zone
Will Noble created CALCITE-6062:
---
Summary: Allow conversion of un-zoned timestamp strings to
timestamp with local time zone
Key: CALCITE-6062
URL: https://issues.apache.org/jira/browse/CALCITE-6062
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Will Noble
[This
function|https://github.com/apache/calcite/blob/ce88348960e95e1c13da850b4422b2f49f022d93/core/src/main/java/org/apache/calcite/runtime/SqlFunctions.java#L4333]
that implements conversion from strings to {{TIMESTAMP WITH LOCAL TIME ZONE}}
uses {{TimestampWithTimeZoneString}}, which seems to have been a subtle mistake.
That function is only used to implement {{CAST}} expressions from strings to TS
w/ LTZ. Those expressions should allow for strings that do not have a time
zone, e.g. {{CAST('2023-10-19 12:00:00' AS TIMESTAMP WITH LOCAL TIME ZONE)}},
but it currently cannot because the {{TimestampWithTimeZoneString}} class
always expects a time zone string.
In the case that no zone is included in the string, we should assume that the
string expresses a timestamp in the data context time zone by defaul.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5884) ARRAY_TO_STRING function should return NULL if its 'nullValue' argument is NULL
[
https://issues.apache.org/jira/browse/CALCITE-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mihai Budiu updated CALCITE-5884:
-
Summary: ARRAY_TO_STRING function should return NULL if its 'nullValue'
argument is NULL (was: Description of ARRAY_TO_STRING function is incomplete)
> ARRAY_TO_STRING function should return NULL if its 'nullValue' argument is
> NULL
> ---
>
> Key: CALCITE-5884
> URL: https://issues.apache.org/jira/browse/CALCITE-5884
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> This is the current definition of the function ARRAY_TO_STRING in
> SqlLibraryOperators:
> {code:java}
> /** The "ARRAY_TO_STRING(array, delimiter [, nullText ])" function. */
> @LibraryOperator(libraries = {BIG_QUERY})
> public static final SqlFunction ARRAY_TO_STRING =
> SqlBasicFunction.create(SqlKind.ARRAY_TO_STRING,
> ReturnTypes.VARCHAR_NULLABLE,
> OperandTypes.STRING_ARRAY_CHARACTER_OPTIONAL_CHARACTER);
> {code}
> So the result is nullable if any of the arguments is nullable. However, the
> nullability of the last argument does not influence the result nullabillity:
> a NULL value for the third optional argument will not cause a NULL value to
> be output.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6055) Customize handling of DateTimeTypeName based on type system
[
https://issues.apache.org/jira/browse/CALCITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1438#comment-1438
]
Will Noble commented on CALCITE-6055:
-
My bad. Added more context to the description. Let me know if anything is still
unclear or if you think the title could still use tweaking.
> Customize handling of DateTimeTypeName based on type system
> ---
>
> Key: CALCITE-6055
> URL: https://issues.apache.org/jira/browse/CALCITE-6055
> Project: Calcite
> Issue Type: Bug
>Reporter: Will Noble
>Priority: Minor
> Labels: pull-request-available
>
> *Background*:
> In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
> minute, and second, henceforth referred to as clock-calendar parameters. This
> does not define an unambiguous instant in time, since timestamps in different
> time zones can have different parameters at the same instant. It is analogous
> to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
> type a different definition: “an absolute point in time, independent of any
> time zone or convention such as Daylight Savings Time.”
> ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
> simply attaches a time zone to the existing {{TIMESTAMP}} type, making it
> _both_ a set of clock-calendar parameters _and_ an unambiguous instant in
> time. The final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle.
> According to Oracle, it “is normalized to the database time zone, and the
> time zone offset is not stored as part of the column data. When users
> retrieve the data, Oracle returns it in the users' local session time zone.”
> This act of conversion between the local time zone and the database time zone
> means that users interacting with this kind of timestamp will observe the
> same instant in time even though they see different clock-calendar
> parameters. However, the local time zone is not considered “part of the
> data”. Thus, it has the semantics of an un-zoned, absolute point in time,
> analogous to a BigQuery {{TIMESTAMP}}.
> This creates the confusing situation where a BigQuery {{DATETIME}} is
> actually an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an
> ISO {{TIMESTAMP WITH LOCAL TIME ZONE}}.
> *Problem*:
> This is very similar to CALCITE-5424, which only applied to literals (e.g.
> {{TIMESTAMP '2023-10-17 12:00:00'}}). We need a similar solution for [the
> {{DateTimeTypeName}}
> construction|https://github.com/apache/calcite/blob/6f79436c178beec639e559d9152c237bbf8ec3e8/core/src/main/codegen/templates/Parser.jj#L6019]
> which is used in other contexts (e.g. {{CAST('2023-10-17 12:00:00' AS
> TIMESTAMP)}}). Seems like we can use a very similar approach: introduce a
> {{DATETIME}} type name, and use {{SqlUserDefinedTypeNameSpec}} for both that
> and the {{TIMESTAMP}} type names. During validation and sql-to-rel
> conversion, we can look up the type names in the UDT map. If no mapping is
> found for {{DATETIME}} (which would occur for any dialect besides BigQuery),
> an error would occur during validation, because that type does not exist in
> that dialect. If no mapping is found for {{TIMESTAMP}}, we would fall back on
> the canonical {{TIMESTAMP}} type, preserving the existing behavior for all
> other dialects.
> *In summary*:
> {{CAST('2023-10-17 12:00:00' AS TIMESTAMP)}} should produce a {{TIMESTAMP
> WITH LOCAL TIME ZONE}} for BigQuery, but a regular {{TIMESTAMP}} for all
> other dialects.
> {{CAST('2023-10-17 12:00:00' AS DATETIME)}} should produce a {{TIMESTAMP}}
> for BigQuery, but throw a validation error for all other dialects.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6055) Customize handling of DateTimeTypeName based on type system
[
https://issues.apache.org/jira/browse/CALCITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble updated CALCITE-6055:
Summary: Customize handling of DateTimeTypeName based on type system (was:
Customize handling of type name based on type system)
> Customize handling of DateTimeTypeName based on type system
> ---
>
> Key: CALCITE-6055
> URL: https://issues.apache.org/jira/browse/CALCITE-6055
> Project: Calcite
> Issue Type: Bug
>Reporter: Will Noble
>Priority: Minor
> Labels: pull-request-available
>
> *Background*:
> In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
> minute, and second, henceforth referred to as clock-calendar parameters. This
> does not define an unambiguous instant in time, since timestamps in different
> time zones can have different parameters at the same instant. It is analogous
> to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
> type a different definition: “an absolute point in time, independent of any
> time zone or convention such as Daylight Savings Time.”
> ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
> simply attaches a time zone to the existing {{TIMESTAMP}} type, making it
> _both_ a set of clock-calendar parameters _and_ an unambiguous instant in
> time. The final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle.
> According to Oracle, it “is normalized to the database time zone, and the
> time zone offset is not stored as part of the column data. When users
> retrieve the data, Oracle returns it in the users' local session time zone.”
> This act of conversion between the local time zone and the database time zone
> means that users interacting with this kind of timestamp will observe the
> same instant in time even though they see different clock-calendar
> parameters. However, the local time zone is not considered “part of the
> data”. Thus, it has the semantics of an un-zoned, absolute point in time,
> analogous to a BigQuery {{TIMESTAMP}}.
> This creates the confusing situation where a BigQuery {{DATETIME}} is
> actually an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an
> ISO {{TIMESTAMP WITH LOCAL TIME ZONE}}.
> *Problem*:
> This is very similar to CALCITE-5424, which only applied to literals (e.g.
> {{TIMESTAMP '2023-10-17 12:00:00'}}). We need a similar solution for [the
> {{DateTimeTypeName}}
> construction|https://github.com/apache/calcite/blob/6f79436c178beec639e559d9152c237bbf8ec3e8/core/src/main/codegen/templates/Parser.jj#L6019]
> which is used in other contexts (e.g. {{CAST('2023-10-17 12:00:00' AS
> TIMESTAMP)}}). Seems like we can use a very similar approach: introduce a
> {{DATETIME}} type name, and use {{SqlUserDefinedTypeNameSpec}} for both that
> and the {{TIMESTAMP}} type names. During validation and sql-to-rel
> conversion, we can look up the type names in the UDT map. If no mapping is
> found for {{DATETIME}} (which would occur for any dialect besides BigQuery),
> an error would occur during validation, because that type does not exist in
> that dialect. If no mapping is found for {{TIMESTAMP}}, we would fall back on
> the canonical {{TIMESTAMP}} type, preserving the existing behavior for all
> other dialects.
> *In summary*:
> {{CAST('2023-10-17 12:00:00' AS TIMESTAMP)}} should produce a {{TIMESTAMP
> WITH LOCAL TIME ZONE}} for BigQuery, but a regular {{TIMESTAMP}} for all
> other dialects.
> {{CAST('2023-10-17 12:00:00' AS DATETIME)}} should produce a {{TIMESTAMP}}
> for BigQuery, but throw a validation error for all other dialects.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6055) Customize handling of type name based on type system
[
https://issues.apache.org/jira/browse/CALCITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble updated CALCITE-6055:
Description:
*Background*:
In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
minute, and second, henceforth referred to as clock-calendar parameters. This
does not define an unambiguous instant in time, since timestamps in different
time zones can have different parameters at the same instant. It is analogous
to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
type a different definition: “an absolute point in time, independent of any
time zone or convention such as Daylight Savings Time.”
ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
simply attaches a time zone to the existing {{TIMESTAMP}} type, making it
_both_ a set of clock-calendar parameters _and_ an unambiguous instant in time.
The final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle.
According to Oracle, it “is normalized to the database time zone, and the time
zone offset is not stored as part of the column data. When users retrieve the
data, Oracle returns it in the users' local session time zone.” This act of
conversion between the local time zone and the database time zone means that
users interacting with this kind of timestamp will observe the same instant in
time even though they see different clock-calendar parameters. However, the
local time zone is not considered “part of the data”. Thus, it has the
semantics of an un-zoned, absolute point in time, analogous to a BigQuery
{{TIMESTAMP}}.
This creates the confusing situation where a BigQuery {{DATETIME}} is actually
an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an ISO
{{TIMESTAMP WITH LOCAL TIME ZONE}}.
*Problem*:
This is very similar to CALCITE-5424, which only applied to literals (e.g.
{{TIMESTAMP '2023-10-17 12:00:00'}}). We need a similar solution for [the
{{DateTimeTypeName}}
construction|https://github.com/apache/calcite/blob/6f79436c178beec639e559d9152c237bbf8ec3e8/core/src/main/codegen/templates/Parser.jj#L6019]
which is used in other contexts (e.g. {{CAST('2023-10-17 12:00:00' AS
TIMESTAMP)}}). Seems like we can use a very similar approach: introduce a
{{DATETIME}} type name, and use {{SqlUserDefinedTypeNameSpec}} for both that
and the {{TIMESTAMP}} type names. During validation and sql-to-rel conversion,
we can look up the type names in the UDT map. If no mapping is found for
{{DATETIME}} (which would occur for any dialect besides BigQuery), an error
would occur during validation, because that type does not exist in that
dialect. If no mapping is found for {{TIMESTAMP}}, we would fall back on the
canonical {{TIMESTAMP}} type, preserving the existing behavior for all other
dialects.
*In summary*:
{{CAST('2023-10-17 12:00:00' AS TIMESTAMP)}} should produce a {{TIMESTAMP WITH
LOCAL TIME ZONE}} for BigQuery, but a regular {{TIMESTAMP}} for all other
dialects.
{{CAST('2023-10-17 12:00:00' AS DATETIME)}} should produce a {{TIMESTAMP}} for
BigQuery, but throw a validation error for all other dialects.
was:
*Background*:
In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
minute, and second, henceforth referred to as clock-calendar parameters. This
does not define an unambiguous instant in time, since timestamps in different
time zones can have different parameters at the same instant. It is analogous
to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
type a different definition: “an absolute point in time, independent of any
time zone or convention such as Daylight Savings Time.”
ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
simply attaches a time zone to the existing {{TIMESTAMP}} type, making it both
a set of clock-calendar parameters _and_ an unambiguous instant in time. The
final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle. According
to Oracle, it “is normalized to the database time zone, and the time zone
offset is not stored as part of the column data. When users retrieve the data,
Oracle returns it in the users' local session time zone.” This act of
conversion between the local time zone and the database time zone means that
users interacting with this kind of timestamp will observe the same instant in
time even though they see different clock-calendar parameters. However, the
local time zone is not considered “part of the data”. Thus, it has the
semantics of an un-zoned, absolute point in time, analogous to a BigQuery
{{TIMESTAMP}}.
This creates the confusing situation where a BigQuery {{DATETIME}} is actually
an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an ISO
{{TIMESTAMP WITH LOCAL TIME ZONE}}.
*Problem*:
This is very similar to CALCITE-5424, which only applied to literals (e.g.
[jira] [Updated] (CALCITE-6055) Customize handling of type name based on type system
[
https://issues.apache.org/jira/browse/CALCITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble updated CALCITE-6055:
Description:
*Background*:
In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
minute, and second, henceforth referred to as clock-calendar parameters. This
does not define an unambiguous instant in time, since timestamps in different
time zones can have different parameters at the same instant. It is analogous
to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
type a different definition: “an absolute point in time, independent of any
time zone or convention such as Daylight Savings Time.”
ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
simply attaches a time zone to the existing {{TIMESTAMP}} type, making it both
a set of clock-calendar parameters _and_ an unambiguous instant in time. The
final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle. According
to Oracle, it “is normalized to the database time zone, and the time zone
offset is not stored as part of the column data. When users retrieve the data,
Oracle returns it in the users' local session time zone.” This act of
conversion between the local time zone and the database time zone means that
users interacting with this kind of timestamp will observe the same instant in
time even though they see different clock-calendar parameters. However, the
local time zone is not considered “part of the data”. Thus, it has the
semantics of an un-zoned, absolute point in time, analogous to a BigQuery
{{TIMESTAMP}}.
This creates the confusing situation where a BigQuery {{DATETIME}} is actually
an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an ISO
{{TIMESTAMP WITH LOCAL TIME ZONE}}.
*Problem*:
This is very similar to CALCITE-5424, which only applied to literals (e.g.
{{TIMESTAMP '2023-10-17 12:00:00'}}). We need a similar solution for [the
{{DateTimeTypeName}}
construction|https://github.com/apache/calcite/blob/6f79436c178beec639e559d9152c237bbf8ec3e8/core/src/main/codegen/templates/Parser.jj#L6019]
which is used in other contexts (e.g. {{CAST('2023-10-17 12:00:00' AS
TIMESTAMP)}}). Seems like we can use a very similar approach: introduce a
{{DATETIME}} type name, and use {{SqlUserDefinedTypeNameSpec}} for both that
and the {{TIMESTAMP}} type names. During validation and sql-to-rel conversion,
we can look up the type names in the UDT map. If no mapping is found for
{{DATETIME}} (which would occur for any dialect besides BigQuery), an error
would occur during validation, because that type does not exist in that
dialect. If no mapping is found for {{TIMESTAMP}}, we would fall back on the
canonical {{TIMESTAMP}} type, preserving the existing behavior for all other
dialects.
*In summary*:
{{CAST('2023-10-17 12:00:00' AS TIMESTAMP)}} should produce a {{TIMESTAMP WITH
LOCAL TIME ZONE}} for BigQuery, but a regular {{TIMESTAMP}} for all other
dialects.
{{CAST('2023-10-17 12:00:00' AS DATETIME)}} should produce a {{TIMESTAMP}} for
BigQuery, but throw a validation error for all other dialects.
was:
Background:
In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
minute, and second, henceforth referred to as clock-calendar parameters. This
does not define an unambiguous instant in time, since timestamps in different
time zones can have different parameters at the same instant. It is analogous
to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
type a different definition: “an absolute point in time, independent of any
time zone or convention such as Daylight Savings Time.”
ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
simply attaches a time zone to the existing {{TIMESTAMP}} type, making it both
a set of clock-calendar parameters and an unambiguous instant in time. The
final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle. According
to Oracle, it “is normalized to the database time zone, and the time zone
offset is not stored as part of the column data. When users retrieve the data,
Oracle returns it in the users' local session time zone.” This act of
conversion between the local time zone and the database time zone means that
users interacting with this kind of timestamp will observe the same instant in
time even though they see different clock-calendar parameters. However, the
local time zone is not considered “part of the data”. Thus, it has the
semantics of an un-zoned, absolute point in time, analogous to a BigQuery
{{TIMESTAMP}}.
This creates the confusing situation where a BigQuery {{DATETIME}} is actually
an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an ISO
{{TIMESTAMP WITH LOCAL TIME ZONE}}.
Problem:
This is very similar to CALCITE-5424, which only applied to literals (e.g.
{{TIMESTAMP
[jira] [Updated] (CALCITE-6055) Customize handling of type name based on type system
[
https://issues.apache.org/jira/browse/CALCITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble updated CALCITE-6055:
Description:
Background:
In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
minute, and second, henceforth referred to as clock-calendar parameters. This
does not define an unambiguous instant in time, since timestamps in different
time zones can have different parameters at the same instant. It is analogous
to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
type a different definition: “an absolute point in time, independent of any
time zone or convention such as Daylight Savings Time.”
ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
simply attaches a time zone to the existing {{TIMESTAMP}} type, making it both
a set of clock-calendar parameters and an unambiguous instant in time. The
final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle. According
to Oracle, it “is normalized to the database time zone, and the time zone
offset is not stored as part of the column data. When users retrieve the data,
Oracle returns it in the users' local session time zone.” This act of
conversion between the local time zone and the database time zone means that
users interacting with this kind of timestamp will observe the same instant in
time even though they see different clock-calendar parameters. However, the
local time zone is not considered “part of the data”. Thus, it has the
semantics of an un-zoned, absolute point in time, analogous to a BigQuery
{{TIMESTAMP}}.
This creates the confusing situation where a BigQuery {{DATETIME}} is actually
an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an ISO
{{TIMESTAMP WITH LOCAL TIME ZONE}}.
Problem:
This is very similar to CALCITE-5424, which only applied to literals (e.g.
{{TIMESTAMP '2023-10-17 12:00:00'}}). We need a similar solution for [the
{{DateTimeTypeName}}
construction|https://github.com/apache/calcite/blob/6f79436c178beec639e559d9152c237bbf8ec3e8/core/src/main/codegen/templates/Parser.jj#L6019]
which is used in other contexts (e.g. {{CAST('2023-10-17 12:00:00' AS
TIMESTAMP)}}). Seems like we can use a very similar approach: introduce a
{{DATETIME}} type name, and use {{SqlUserDefinedTypeNameSpec}} for both that
and the {{TIMESTAMP}} type names. During validation and sql-to-rel conversion,
we can look up the type names in the UDT map. If no mapping is found for
{{DATETIME}} (which would occur for any dialect besides BigQuery), an error
would occur during validation, because that type does not exist in that
dialect. If no mapping is found for {{TIMESTAMP}}, we would fall back on the
canonical {{TIMESTAMP}} type, preserving the existing behavior for all other
dialects.
In summary:
{{CAST('2023-10-17 12:00:00' AS TIMESTAMP)}} should produce a {{TIMESTAMP WITH
LOCAL TIME ZONE}} for BigQuery, but a regular {{TIMESTAMP}} for all other
dialects.
{{CAST('2023-10-17 12:00:00' AS DATETIME)}} should produce a {{TIMESTAMP}} for
BigQuery, but throw a validation error for all other dialects.
was:
Background:
In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
minute, and second, henceforth referred to as clock-calendar parameters. This
does not define an unambiguous instant in time, since timestamps in different
time zones can have different parameters at the same instant. It is analogous
to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
type a different definition: “an absolute point in time, independent of any
time zone or convention such as Daylight Savings Time.”
ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
simply attaches a time zone to the existing {{TIMESTAMP}} type, making it both
a set of clock-calendar parameters and an unambiguous instant in time. The
final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle. According
to Oracle, it “is normalized to the database time zone, and the time zone
offset is not stored as part of the column data. When users retrieve the data,
Oracle returns it in the users' local session time zone.” This act of
conversion between the local time zone and the database time zone means that
users interacting with this kind of timestamp will observe the same instant in
time even though they see different clock-calendar parameters. However, the
local time zone is not considered “part of the data”. Thus, it has the
semantics of an un-zoned, absolute point in time, analogous to a BigQuery
{{TIMESTAMP}}.
This creates the confusing situation where a BigQuery {{DATETIME}} is actually
an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an ISO
{{TIMESTAMP WITH LOCAL TIME ZONE}}.
Problem:
This is very similar to CALCITE-5424, which only applied to literals (e.g.
{{TIMESTAMP '2023-10-17
[jira] [Updated] (CALCITE-6055) Customize handling of type name based on type system
[
https://issues.apache.org/jira/browse/CALCITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble updated CALCITE-6055:
Description:
Background:
In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
minute, and second, henceforth referred to as clock-calendar parameters. This
does not define an unambiguous instant in time, since timestamps in different
time zones can have different parameters at the same instant. It is analogous
to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
type a different definition: “an absolute point in time, independent of any
time zone or convention such as Daylight Savings Time.”
ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
simply attaches a time zone to the existing {{TIMESTAMP}} type, making it both
a set of clock-calendar parameters and an unambiguous instant in time. The
final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle. According
to Oracle, it “is normalized to the database time zone, and the time zone
offset is not stored as part of the column data. When users retrieve the data,
Oracle returns it in the users' local session time zone.” This act of
conversion between the local time zone and the database time zone means that
users interacting with this kind of timestamp will observe the same instant in
time even though they see different clock-calendar parameters. However, the
local time zone is not considered “part of the data”. Thus, it has the
semantics of an un-zoned, absolute point in time, analogous to a BigQuery
{{TIMESTAMP}}.
This creates the confusing situation where a BigQuery {{DATETIME}} is actually
an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an ISO
{{TIMESTAMP WITH LOCAL TIME ZONE}}.
Problem:
This is very similar to CALCITE-5424, which only applied to literals (e.g.
{{TIMESTAMP '2023-10-17 12:00:00'}}). We need a similar solution for [the
{{DateTimeTypeName}}
construction|https://github.com/apache/calcite/blob/6f79436c178beec639e559d9152c237bbf8ec3e8/core/src/main/codegen/templates/Parser.jj#L6019]
which is used in other contexts (e.g. {{CAST('2023-10-17 12:00:00' AS
TIMESTAMP)}}). Seems like we can use a very similar approach: introduce a
{{DATETIME}} type name, and use {{SqlUserDefinedTypeNameSpec}} for both that
and the {{TIMESTAMP}} type names. During validation and sql-to-rel conversion,
we can look up the type names in the UDT map. If no mapping is found for
{{DATETIME}} (which would occur for any dialect besides BigQuery), an error
would occur during validation, because that type does not exist in that
dialect. If no mapping is found for {{TIMESTAMP}}, we would fall back on the
canonical {{TIMESTAMP}} type, preserving the existing behavior for all other
dialects.
was:
Background:
In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
minute, and second, henceforth referred to as clock-calendar parameters. This
does not define an unambiguous instant in time, since timestamps in different
time zones can have different parameters at the same instant. It is analogous
to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
type a different definition: “an absolute point in time, independent of any
time zone or convention such as Daylight Savings Time.”
ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
simply attaches a time zone to the existing {{TIMESTAMP}} type, making it both
a set of clock-calendar parameters and an unambiguous instant in time. The
final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle. According
to Oracle, it “is normalized to the database time zone, and the time zone
offset is not stored as part of the column data. When users retrieve the data,
Oracle returns it in the users' local session time zone.” This act of
conversion between the local time zone and the database time zone means that
users interacting with this kind of timestamp will observe the same instant in
time even though they see different clock-calendar parameters. However, the
local time zone is not considered “part of the data”. Thus, it has the
semantics of an un-zoned, absolute point in time, analogous to a BigQuery
{{TIMESTAMP}}.
This creates the confusing situation where a BigQuery {{DATETIME}} is actually
an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an ISO
{{TIMESTAMP WITH LOCAL TIME ZONE}}.
Problem:
This is very similar to CALCITE-5424, which only applied to literals (e.g.
{{TIMESTAMP '2023-10-17 12:00:00'}}). We need a similar solution for [the
{{DateTimeTypeName}}
construction|https://github.com/apache/calcite/blob/6f79436c178beec639e559d9152c237bbf8ec3e8/core/src/main/codegen/templates/Parser.jj#L6019]
which is used in other contexts (e.g. {{CAST('2023-10-17 12:00:00' AS
TIMESTAMP)}}). Seems like we can use
[jira] [Updated] (CALCITE-6055) Customize handling of type name based on type system
[
https://issues.apache.org/jira/browse/CALCITE-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Will Noble updated CALCITE-6055:
Description:
Background:
In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
minute, and second, henceforth referred to as clock-calendar parameters. This
does not define an unambiguous instant in time, since timestamps in different
time zones can have different parameters at the same instant. It is analogous
to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
type a different definition: “an absolute point in time, independent of any
time zone or convention such as Daylight Savings Time.”
ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
simply attaches a time zone to the existing {{TIMESTAMP}} type, making it both
a set of clock-calendar parameters and an unambiguous instant in time. The
final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle. According
to Oracle, it “is normalized to the database time zone, and the time zone
offset is not stored as part of the column data. When users retrieve the data,
Oracle returns it in the users' local session time zone.” This act of
conversion between the local time zone and the database time zone means that
users interacting with this kind of timestamp will observe the same instant in
time even though they see different clock-calendar parameters. However, the
local time zone is not considered “part of the data”. Thus, it has the
semantics of an un-zoned, absolute point in time, analogous to a BigQuery
{{TIMESTAMP}}.
This creates the confusing situation where a BigQuery {{DATETIME}} is actually
an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an ISO
{{TIMESTAMP WITH LOCAL TIME ZONE}}.
Problem:
This is very similar to CALCITE-5424, which only applied to literals (e.g.
{{TIMESTAMP '2023-10-17 12:00:00'}}). We need a similar solution for [the
{{DateTimeTypeName}}
construction|https://github.com/apache/calcite/blob/6f79436c178beec639e559d9152c237bbf8ec3e8/core/src/main/codegen/templates/Parser.jj#L6019]
which is used in other contexts (e.g. {{CAST('2023-10-17 12:00:00' AS
TIMESTAMP)}}). Seems like we can use a very similar approach: introduce a
{{SqlUnknownTypeNameSpec}} that's resolved during validation.
was:This is very similar to CALCITE-5424, which only applied to literals
(e.g. {{TIMESTAMP '2023-10-17 12:00:00'}}). We need a similar solution for [the
{{DateTimeTypeName}}
construction|https://github.com/apache/calcite/blob/6f79436c178beec639e559d9152c237bbf8ec3e8/core/src/main/codegen/templates/Parser.jj#L6019]
which is used in other contexts (e.g. {{CAST('2023-10-17 12:00:00' AS
TIMESTAMP)}}). Seems like we can use a very similar approach: introduce a
{{SqlUnknownTypeNameSpec}} that's resolved during validation.
> Customize handling of type name based on type system
>
>
> Key: CALCITE-6055
> URL: https://issues.apache.org/jira/browse/CALCITE-6055
> Project: Calcite
> Issue Type: Bug
>Reporter: Will Noble
>Priority: Minor
> Labels: pull-request-available
>
> Background:
> In ISO SQL, a {{TIMESTAMP}} comprises the parameters year, month, day, hour,
> minute, and second, henceforth referred to as clock-calendar parameters. This
> does not define an unambiguous instant in time, since timestamps in different
> time zones can have different parameters at the same instant. It is analogous
> to a BigQuery {{DATETIME}}. BigQuery chose to give its native {{TIMESTAMP}}
> type a different definition: “an absolute point in time, independent of any
> time zone or convention such as Daylight Savings Time.”
> ISO SQL has 2 other {{TIMESTAMP}} types. The {{TIMESTAMP WITH TIME ZONE}}
> simply attaches a time zone to the existing {{TIMESTAMP}} type, making it
> both a set of clock-calendar parameters and an unambiguous instant in time.
> The final type -- {{TIMESTAMP WITH LOCAL TIME ZONE}} -- is more subtle.
> According to Oracle, it “is normalized to the database time zone, and the
> time zone offset is not stored as part of the column data. When users
> retrieve the data, Oracle returns it in the users' local session time zone.”
> This act of conversion between the local time zone and the database time zone
> means that users interacting with this kind of timestamp will observe the
> same instant in time even though they see different clock-calendar
> parameters. However, the local time zone is not considered “part of the
> data”. Thus, it has the semantics of an un-zoned, absolute point in time,
> analogous to a BigQuery {{TIMESTAMP}}.
> This creates the confusing situation where a BigQuery {{DATETIME}} is
> actually an ISO {{TIMESTAMP}}, and a BigQuery {{TIMESTAMP}} is actually an
>
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1429#comment-1429
]
Ruben Q L commented on CALCITE-6061:
Agree with [~julianhyde] and [~mbudiu]. Even if the specification says that
"the order is not guaranteed", that does not mean that "the order must not be
guaranteed" (as the description of the current ticket seems to imply).
Using a LinkedHashMap is totally valid, and has some advantages (as others have
mentioned before).
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time.
> {code:java}
> +-+
> | EXPR$0 |
> +-+
> | {1=2, 3=4, 5=6} |
> +-+
> {code}
> because calcite use LinkedHashMap for storage. But semantically, the order
> should not be guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +++
> | op | EXPR$0 |
> +++
> | +I | {5=6, 1=2, 3=4} |
> +++
> Received a total of 1 row {code}
> it will return different order when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1400#comment-1400
]
Julian Hyde commented on CALCITE-6061:
--
{quote}from a runtime perspective, should we return a hashmap?{quote}
I don't think we *return* anything. People can get the data via JDBC. But the
fact that we happen to store the data in a {{LinkedHashMap}} (or other java
class) while computing the result is an implementation detail.
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time.
> {code:java}
> +-+
> | EXPR$0 |
> +-+
> | {1=2, 3=4, 5=6} |
> +-+
> {code}
> because calcite use LinkedHashMap for storage. But semantically, the order
> should not be guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +++
> | op | EXPR$0 |
> +++
> | +I | {5=6, 1=2, 3=4} |
> +++
> Received a total of 1 row {code}
> it will return different order when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1391#comment-1391
]
Ran Tao commented on CALCITE-6061:
--
IMHO, Because we should follow the definition of MAP itself, LinkedHashMap or
TreeMap, etc. are special implementations.
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time.
> {code:java}
> +-+
> | EXPR$0 |
> +-+
> | {1=2, 3=4, 5=6} |
> +-+
> {code}
> because calcite use LinkedHashMap for storage. But semantically, the order
> should not be guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +++
> | op | EXPR$0 |
> +++
> | +I | {5=6, 1=2, 3=4} |
> +++
> Received a total of 1 row {code}
> it will return different order when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1379#comment-1379
]
Mihai Budiu commented on CALCITE-6061:
--
Why not just Map?
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time.
> {code:java}
> +-+
> | EXPR$0 |
> +-+
> | {1=2, 3=4, 5=6} |
> +-+
> {code}
> because calcite use LinkedHashMap for storage. But semantically, the order
> should not be guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +++
> | op | EXPR$0 |
> +++
> | +I | {5=6, 1=2, 3=4} |
> +++
> Received a total of 1 row {code}
> it will return different order when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5884) Description of ARRAY_TO_STRING function is incomplete
[
https://issues.apache.org/jira/browse/CALCITE-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1373#comment-1373
]
Julian Hyde commented on CALCITE-5884:
--
I have reviewed.
A better summary, in my opinion, is "ARRAY_TO_STRING function should return
NULL if its 'nullValue' argument is NULL". It says what was wrong about the
description, and what the correct and new behavior is.
> Description of ARRAY_TO_STRING function is incomplete
> -
>
> Key: CALCITE-5884
> URL: https://issues.apache.org/jira/browse/CALCITE-5884
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Mihai Budiu
>Assignee: Mihai Budiu
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> This is the current definition of the function ARRAY_TO_STRING in
> SqlLibraryOperators:
> {code:java}
> /** The "ARRAY_TO_STRING(array, delimiter [, nullText ])" function. */
> @LibraryOperator(libraries = {BIG_QUERY})
> public static final SqlFunction ARRAY_TO_STRING =
> SqlBasicFunction.create(SqlKind.ARRAY_TO_STRING,
> ReturnTypes.VARCHAR_NULLABLE,
> OperandTypes.STRING_ARRAY_CHARACTER_OPTIONAL_CHARACTER);
> {code}
> So the result is nullable if any of the arguments is nullable. However, the
> nullability of the last argument does not influence the result nullabillity:
> a NULL value for the third optional argument will not cause a NULL value to
> be output.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-6061:
-
Description:
when we call:
{code:java}
select map[1,2,3,4,5,6];{code}
The order of results returned is the same every time.
{code:java}
+-+
| EXPR$0 |
+-+
| {1=2, 3=4, 5=6} |
+-+
{code}
because calcite use LinkedHashMap for storage. But semantically, the order
should not be guaranteed just like MULTISET.
we can see other engines such as apache spark/flink just use HashMap in this
case.
{code:java}
Flink SQL> select map[1,2,3,4,5,6];
+++
| op | EXPR$0 |
+++
| +I | {5=6, 1=2, 3=4} |
+++
Received a total of 1 row {code}
it will return different order when you call it.
[https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
was:
when we call:
{code:java}
select map[1,2,3,4,5,6];{code}
The order of results returned is the same every time. because calcite use
LinkedHashMap for storage. But semantically, the order should not be guaranteed
just like MULTISET.
we can see other engines such as apache spark/flink just use HashMap in this
case.
{code:java}
Flink SQL> select map[1,2,3,4,5,6];
+++
| op | EXPR$0 |
+++
| +I | {5=6, 1=2, 3=4} |
+++
Received a total of 1 row {code}
it will return different order when you call it.
[https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time.
> {code:java}
> +-+
> | EXPR$0 |
> +-+
> | {1=2, 3=4, 5=6} |
> +-+
> {code}
> because calcite use LinkedHashMap for storage. But semantically, the order
> should not be guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +++
> | op | EXPR$0 |
> +++
> | +I | {5=6, 1=2, 3=4} |
> +++
> Received a total of 1 row {code}
> it will return different order when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1369#comment-1369
]
Ran Tao commented on CALCITE-6061:
--
In general, I agree with you, but I don't agree with you very much about the
test. For the test, we can ensure that the order is fixed through other way,
but from a runtime perspective, should we return a hashmap?
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time. because calcite use
> LinkedHashMap for storage. But semantically, the order should not be
> guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +++
> | op | EXPR$0 |
> +++
> | +I | {5=6, 1=2, 3=4} |
> +++
> Received a total of 1 row {code}
> it will return different order when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-6061:
-
Description:
when we call:
{code:java}
select map[1,2,3,4,5,6];{code}
The order of results returned is the same every time. because calcite use
LinkedHashMap for storage. But semantically, the order should not be guaranteed
just like MULTISET.
we can see other engines such as apache spark/flink just use HashMap in this
case.
{code:java}
Flink SQL> select map[1,2,3,4,5,6];
+++
| op | EXPR$0 |
+++
| +I | {5=6, 1=2, 3=4} |
+++
Received a total of 1 row {code}
it will return different order when you call it.
[https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
was:
when we call:
{code:java}
select map[1,2,3,4,5,6];{code}
The order of results returned is the same every time. because calcite use
LinkedHashMap for storage. But semantically, the order should not be guaranteed
just like MULTISET.
we can see other engines such as apache spark/flink just use HashMap in this
case.
{code:java}
Flink SQL> select map[1,2,3,4,5,6];
+++
| op | EXPR$0 |
+++
| +I | {5=6, 1=2, 3=4} |
+++
Received a total of 1 row {code}
it will return different result when you call it.
[https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time. because calcite use
> LinkedHashMap for storage. But semantically, the order should not be
> guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +++
> | op | EXPR$0 |
> +++
> | +I | {5=6, 1=2, 3=4} |
> +++
> Received a total of 1 row {code}
> it will return different order when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-6061:
-
Description:
when we call:
{code:java}
select map[1,2,3,4,5,6];{code}
The order of results returned is the same every time. because calcite use
LinkedHashMap for storage. But semantically, the order should not be guaranteed
just like MULTISET.
we can see other engines such as apache spark/flink just use HashMap in this
case.
{code:java}
Flink SQL> select map[1,2,3,4,5,6];
+++
| op | EXPR$0 |
+++
| +I | {5=6, 1=2, 3=4} |
+++
Received a total of 1 row {code}
it will return different result when you call it.
[https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
was:
when we call:
{code:java}
select map[1,2,3,4];{code}
The order of results returned is the same every time. because calcite use
LinkedHashMap for storage. But semantically, the order should not be guaranteed
just like MULTISET.
we can see other engines such as apache spark/flink just use HashMap in this
case.
[https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4,5,6];{code}
> The order of results returned is the same every time. because calcite use
> LinkedHashMap for storage. But semantically, the order should not be
> guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> {code:java}
> Flink SQL> select map[1,2,3,4,5,6];
> +++
> | op | EXPR$0 |
> +++
> | +I | {5=6, 1=2, 3=4} |
> +++
> Received a total of 1 row {code}
> it will return different result when you call it.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1366#comment-1366
]
Julian Hyde commented on CALCITE-6061:
--
I agree with [~mbudiu] that it's not a bug. The specification does not
guarantee order but it's ok if our implementation has deterministic order. (I
know it's a rather subtle point, because there is only one implementation of
the specification.)
In fact, if our implementation is deterministic, it makes it easier for us to
test.
When does the specification matter? One example. If we were to implement an
'equals' operation between two maps, the maps would be equal if they have the
same keys and values, regardless of order.
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4];{code}
> The order of results returned is the same every time. because calcite use
> LinkedHashMap for storage. But semantically, the order should not be
> guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1346#comment-1346
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 4:42 PM:
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters to support this 'array()' form rather
than support orderby or limit). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno desc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
select array(select empno from emps order by empno asc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
{code}
the orderby will not work.
So what I want to illustrate here is that calcite parser originally does not
support orderby/limit for array/map/multiset sub-query.
was (Author: lemonjing):
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters to support this 'array()' form rather
than support orderby or limit). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno desc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
select array(select empno from emps order by empno asc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
{code}
the orderby will not work.
So what I want to illustrate here is that calcite parser originally does not
support orderby/limit for array/map/multiset.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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)
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1346#comment-1346
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 4:41 PM:
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters to support this 'array()' form rather
than support orderby or limit). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno desc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
select array(select empno from emps order by empno asc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
{code}
the orderby will not work.
So what I want to illustrate here is that calcite parser originally does not
support orderby/limit for array/map/multiset.
was (Author: lemonjing):
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters to support this 'array()' form rather
than support orderby or limit). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno desc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
select array(select empno from emps order by empno asc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
{code}
the order by will not work.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Updated] (CALCITE-6061) MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-6061:
-
Summary: MapValueConstructor/MapQueryConstructor use LinkedHashMap
erroneously (was: MapValueConstrcutor/MapQueryConstructor use LinkedHashMap
erroneously)
> MapValueConstructor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4];{code}
> The order of results returned is the same every time. because calcite use
> LinkedHashMap for storage. But semantically, the order should not be
> guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1365#comment-1365
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 4:39 PM:
thanks Julian for explanations. I will fix/support some questions/ability above
in follow-up ticket.
was (Author: lemonjing):
thanks Julian for explanations. I will fix/support some questions above in
follow-up ticket.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Commented] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1365#comment-1365
]
Ran Tao commented on CALCITE-6041:
--
thanks Julian for explanations. I will fix/support some questions above in
follow-up ticket.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1346#comment-1346
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 4:35 PM:
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters to support this 'array()' form rather
than support orderby or limit). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno desc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
select array(select empno from emps order by empno asc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
{code}
the order by will not work.
was (Author: lemonjing):
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno desc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
select array(select empno from emps order by empno asc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
{code}
the order by will not work.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6061) MapValueConstrcutor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1358#comment-1358
]
Ran Tao edited comment on CALCITE-6061 at 10/19/23 4:28 PM:
[~mbudiu] thanks for reviewing. Julian also explain this in CALCITE-6041 .
make sense to me.
was (Author: lemonjing):
[~mbudiu] thanks for reviewing. Julian also explain this in another issue.
make sense to me.
> MapValueConstrcutor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4];{code}
> The order of results returned is the same every time. because calcite use
> LinkedHashMap for storage. But semantically, the order should not be
> guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (CALCITE-6041) MAP sub-query gives NullPointerException
[ https://issues.apache.org/jira/browse/CALCITE-6041 ]
Ran Tao deleted comment on CALCITE-6041:
--
was (Author: lemonjing):
got it, maybe we need to confirm which step changed the order. It may be a
problem with SQLLine or Quidem or test printing, not the array itself.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Commented] (CALCITE-5612) Babel parser should support PostgreSQL's SET TRANSACTION command
[
https://issues.apache.org/jira/browse/CALCITE-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1362#comment-1362
]
Julian Hyde commented on CALCITE-5612:
--
This case illustrates something I've been saying for a long time: Don't ask me
to review things. If my name is against a case/PR others will be less inclined
to review it.
I often comment when a jira case is first logged. I'm trying to make sure that
the project is headed in the right direction. After I've made those comments, I
have very little time to review iterations of the PR.
> Babel parser should support PostgreSQL's SET TRANSACTION command
>
>
> Key: CALCITE-5612
> URL: https://issues.apache.org/jira/browse/CALCITE-5612
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.34.0
>Reporter: Dmitry Sysolyatin
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Labels: pull-request-available
>
> SET TRANSACTION — set the characteristics of the current transaction
> Specification [1]:
> {code}
> SET TRANSACTION transaction_mode [, ...]
> SET TRANSACTION SNAPSHOT snapshot_id
> SET SESSION CHARACTERISTICS AS TRANSACTION transaction_mode [, ...]
> where transaction_mode is one of:
> ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ
> UNCOMMITTED }
> READ WRITE | READ ONLY
> [ NOT ] DEFERRABLE
> {code}
> [1] https://www.postgresql.org/docs/current/sql-set-transaction.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6061) MapValueConstrcutor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1358#comment-1358
]
Ran Tao commented on CALCITE-6061:
--
[~mbudiu] thanks for reviewing. Julian also explain this in another issue.
make sense to me.
> MapValueConstrcutor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4];{code}
> The order of results returned is the same every time. because calcite use
> LinkedHashMap for storage. But semantically, the order should not be
> guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1357#comment-1357
]
Ran Tao commented on CALCITE-6041:
--
got it, maybe we need to confirm which step changed the order. It may be a
problem with QLLine or Quidem or test printing, not the array itself.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1357#comment-1357
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 4:17 PM:
got it, maybe we need to confirm which step changed the order. It may be a
problem with SQLLine or Quidem or test printing, not the array itself.
was (Author: lemonjing):
got it, maybe we need to confirm which step changed the order. It may be a
problem with QLLine or Quidem or test printing, not the array itself.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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] [Commented] (CALCITE-6061) MapValueConstrcutor/MapQueryConstructor use LinkedHashMap erroneously
[
https://issues.apache.org/jira/browse/CALCITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1355#comment-1355
]
Mihai Budiu commented on CALCITE-6061:
--
This doesn't sound like a bug to me.
The semantics prescribes a set of possible legal behaviors for a program, and
this is one of them.
At most this could be a feature. There are two possible reasons this may be
desirable:
* better performance
* more thorough testing
> MapValueConstrcutor/MapQueryConstructor use LinkedHashMap erroneously
> -
>
> Key: CALCITE-6061
> URL: https://issues.apache.org/jira/browse/CALCITE-6061
> Project: Calcite
> Issue Type: Bug
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Priority: Major
>
> when we call:
> {code:java}
> select map[1,2,3,4];{code}
> The order of results returned is the same every time. because calcite use
> LinkedHashMap for storage. But semantically, the order should not be
> guaranteed just like MULTISET.
> we can see other engines such as apache spark/flink just use HashMap in this
> case.
> [https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1346#comment-1346
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 4:12 PM:
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno desc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
select array(select empno from emps order by empno asc);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+
{code}
the order by will not work.
was (Author: lemonjing):
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+{code}
the order by will not work.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1346#comment-1346
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 4:11 PM:
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
for example, this sql:
{code:java}
select array(select empno from emps order by empno);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+{code}
the order by will not work.
was (Author: lemonjing):
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
and such as the sql:
{code:java}
select array(select empno from emps order by empno);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+{code}
the order by will not work.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Commented] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1346#comment-1346
]
Ran Tao commented on CALCITE-6041:
--
FYI, the array allows OrderBy was intrdoced by this
[https://github.com/apache/calcite/pull/3141] PR by mistake (The processing
here is just to receive all parameters). It accept all exprs.
But in fact there is no test case, and even the correctness is problematic. we
need another ticket to refine this if we decide to support it.
and such as the sql:
{code:java}
select array(select empno from emps order by empno);
+---+
| EXPR$0 |
+---+
| [100, 110, 110, 120, 130] |
+---+{code}
the order by will not work.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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)
>
[jira] [Created] (CALCITE-6061) MapValueConstrcutor/MapQueryConstructor use LinkedHashMap erroneously
Ran Tao created CALCITE-6061:
Summary: MapValueConstrcutor/MapQueryConstructor use LinkedHashMap
erroneously
Key: CALCITE-6061
URL: https://issues.apache.org/jira/browse/CALCITE-6061
Project: Calcite
Issue Type: Bug
Affects Versions: 1.35.0
Reporter: Ran Tao
when we call:
{code:java}
select map[1,2,3,4];{code}
The order of results returned is the same every time. because calcite use
LinkedHashMap for storage. But semantically, the order should not be guaranteed
just like MULTISET.
we can see other engines such as apache spark/flink just use HashMap in this
case.
[https://github.com/apache/flink/blob/a2681f6a85aaad21179f91e03a91b4a05158841e/flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/codegen/ExprCodeGenerator.scala#L711]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1340#comment-1340
]
Julian Hyde commented on CALCITE-6041:
--
I can see why {{ARRAY}} allows {{ORDER BY}}. It is an ordered collection.
Since {{MAP}} is not in the standard, it is not fully specified. But I would
say that it is an unordered collection: map values are equal if they have the
same keys and values, regardless of the order in which they appear.
Implementations of MAP may give people the impression that the map preserves
order, but it does not.
There are comparisons with JSON's "object" type. Many implementations will use
Java's {{LinkedHashMap}}, that preserves order. But the JSON standard defines
objects as "an unordered collection of zero or more name/value pairs".
It would be nice if there was a way to apply an order as we iterate over a
{MAP}} value. I guess {{UNNEST}} + {{ORDER BY}} can achieve that.
It would also be nice if clients (e.g. SQLLine and Quidem) sort maps into a
deterministic order as they print them.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:35 PM:
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy (the parser use LeafQueryOrExpr not allow
OrderBy/LIMIT).
however, the sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
Generally speaking, MULTISET without OrderBy is reasonable. but maybe we can
support array sub-query with OrderBy. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
MULTISET, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later.
was (Author: lemonjing):
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy (the parser use LeafQueryOrExpr not allow
OrderBy/LIMIT).
however, the sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
MULTISET without OrderBy is reasonable. but maybe we can support array
sub-query with OrderBy. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
MULTISET, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:34 PM:
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy (the parser use LeafQueryOrExpr not allow
OrderBy/LIMIT).
however, the sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
MULTISET without OrderBy is reasonable. but maybe we can support array
sub-query with OrderBy. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
MULTISET, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later.
was (Author: lemonjing):
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
MULTISET without OrderBy is reasonable. but maybe we can support array
sub-query with OrderBy. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
MULTISET, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:29 PM:
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
MULTISET without OrderBy is reasonable. but maybe we can support array
sub-query with OrderBy. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
MULTISET, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later.
was (Author: lemonjing):
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:29 PM:
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later.
was (Author: lemonjing):
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:27 PM:
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later or follow-up ticket.
was (Author: lemonjing):
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this issue,
and we can record or support it later or follow-up ticket.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:27 PM:
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later.
was (Author: lemonjing):
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm asking this because if we use LinkedHashMap
then if we support OrderBy, we will get deterministic result for MAP. I'm not
sure if this is expected.
But in any case, the support of OrderBy or LIMIT is orthogonal to this issue,
and we can record or support it later or follow-up ticket.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:24 PM:
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array query with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this issue,
and we can record or support it later or follow-up ticket.
was (Author: lemonjing):
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this issue,
and we can record or support it later or follow-up ticket.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:24 PM:
By checking the code and sql standard. I have got some context/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this issue,
and we can record or support it later or follow-up ticket.
was (Author: lemonjing):
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this issue,
and we can record or support it later or follow-up ticket.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:24 PM:
By checking the code and sql standard. I have got some background/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this issue,
and we can record or support it later or follow-up ticket.
was (Author: lemonjing):
By checking the code and sql standard. I have got some context/informations:
calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this issue,
and we can record or support it later or follow-up ticket.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:16 PM:
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this issue,
and we can record or support it later or follow-up ticket.
was (Author: lemonjing):
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this ISSUE,
and we can record or support it later.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:15 PM:
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this ISSUE,
and we can record or support it later.
was (Author: lemonjing):
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed either)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this ISSUE,
and we can record or support it later.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:14 PM:
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ]
{code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed either)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this ISSUE,
and we can record or support it later.
was (Author: lemonjing):
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ] {code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed either)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this ISSUE,
and we can record or support it later.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:13 PM:
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003 allows array with orderby:
{code:java}
::=
ARRAY [ ] {code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed either)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this ISSUE,
and we can record or support it later.
was (Author: lemonjing):
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,dept from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003 allows array with orderby:
{code:java}
::=
ARRAY [ ] {code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed either)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this ISSUE,
and we can record or support it later.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Comment Edited] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao edited comment on CALCITE-6041 at 10/19/23 3:14 PM:
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003, 6.36 allows array with orderby:
{code:java}
::=
ARRAY [ ] {code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed either)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this ISSUE,
and we can record or support it later.
was (Author: lemonjing):
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,deptno from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003 allows array with orderby:
{code:java}
::=
ARRAY [ ] {code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed either)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this ISSUE,
and we can record or support it later.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Commented] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1321#comment-1321
]
Ran Tao commented on CALCITE-6041:
--
By checking the code and sql standard. calcite currently support:
{code:java}
select array(select empno from emps [where...]);
select multiset(select empno from emps [where...]);
select map(select empno,dept from emps [where...]); {code}
they can not use LIMIT or OrderBy.
however, the new sql-standard-2003 allows array with orderby:
{code:java}
::=
ARRAY [ ] {code}
{code:java}
::=
MULTISET {code}
multiset without orderby is reasonable. but maybe we can support array
sub-query with orderby. (whether to support LIMIT? need discussed either)
Considering MAP sub-query, it is not a sql standard collection. We can discuss
it, but in terms of map characteristics, it should be unordered similar to
multiset, but my question is that currently calcite uses LinkedHashMap for
storage, ensuring the order. I'm not sure if this is expected.
But in any case, the support of orderby or limit is orthogonal to this ISSUE,
and we can record or support it later.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Updated] (CALCITE-6042) Add test cases for ARRAY-related functions by using spark array function
[
https://issues.apache.org/jira/browse/CALCITE-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ran Tao updated CALCITE-6042:
-
Summary: Add test cases for ARRAY-related functions by using spark array
function (was: Add test cases for ARRAY-related functions by using spark array
function (Spark Library))
> Add test cases for ARRAY-related functions by using spark array function
>
>
> Key: CALCITE-6042
> URL: https://issues.apache.org/jira/browse/CALCITE-6042
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> Currently, we support a serials of Spark ARRAY functions such as
> ARRAY/ARRAY_DISTINCT/ARRAY_EXCEPT/ARRAY_POSITION/ARRAY_CONTAINS...
> however, the test cases of these functions use calcite array constructor such
> as
> {code:java}
> array_except(array[2], array[2, 3]) {code}
> We don't have any testcase related to the Spark's array function, however
> this is actually important. Because these array functions belong to Spark
> library, and the Spark's array has some different behaviors with calcite's
> array constructor.
> # use array(expr, ...) rather than array[expr, ...]
> # allows empty array such as array(); however calcite array constructor not
> support it.
> # spark array supports some special cases such as array(1, 'x')
> we expect to add some test cases like:
> {code:java}
> array_except(array(2), array(2, 3))
> array_except(array(2), array()) {code}
> Frankly speaking, if the user activates the spark library, it is more natural
> for them to use the array() function rather than array[]. We should treat it
> as 2 functions for testing and coverage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-6037) The function category of ARRAY/EXTRACT_VALUE/XML_TRANSFORM/EXTRACT_XML/EXISTSNODE is incorrect
[ https://issues.apache.org/jira/browse/CALCITE-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ran Tao updated CALCITE-6037: - Summary: The function category of ARRAY/EXTRACT_VALUE/XML_TRANSFORM/EXTRACT_XML/EXISTSNODE is incorrect (was: The function category of ARRAY/EXTRACT_VALUE/XML_TRANSFORM/EXTRACT_XML/EXISTSNODE is incorrect (Spark/MySQL/Oracle Library)) > The function category of > ARRAY/EXTRACT_VALUE/XML_TRANSFORM/EXTRACT_XML/EXISTSNODE is incorrect > -- > > Key: CALCITE-6037 > URL: https://issues.apache.org/jira/browse/CALCITE-6037 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.35.0 >Reporter: Ran Tao >Assignee: Ran Tao >Priority: Major > Labels: pull-request-available > Fix For: 1.36.0 > > > Currently some functions do not specify a category name. > It will cause the error function category: > > ||function name||current category||desired category|| > |ARRAY (Spark)|Numeric|System| > |EXTRACT_VALUE (MySQL)|Numeric|String| > |XML_TRANSFORM (Oracle)|Numeric|String| > |EXTRACT_XML (Oracle)|Numeric|String| > |EXISTSNODE (Oracle)|Numeric|String| > the definition of function category in ANSI-SQL (not very sure this is the > sql standard, but the implementation of calcite is similar to it) can be > found at: > [https://www.oreilly.com/library/view/sql-in-a/9780596155322/ch04s04.html.|http://users.atw.hu/sqlnut/sqlnut2-chp-4-sect-4.html#sqlnut2-CHP-4-SECT-4.1] > Generally speaking, these functions (except ARRAY) process XML text and > conform to the definition of String category rather than Numeric. > btw, because they use a simplified constructor of SqlBasicFunction, the > function category is always set to Numeric. We need to set the desired > function category. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CALCITE-6041) MAP sub-query gives NullPointerException
[
https://issues.apache.org/jira/browse/CALCITE-6041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1158#comment-1158
]
Ran Tao commented on CALCITE-6041:
--
thanks for reviewing. updated the tests.
> MAP sub-query gives NullPointerException
>
>
> Key: CALCITE-6041
> URL: https://issues.apache.org/jira/browse/CALCITE-6041
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.35.0
>Reporter: Ran Tao
>Assignee: Ran Tao
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> calcite support array/map/multiset query constructor, but if we run map query
> such as:
> {code:java}
> select map(select 1, 2)
> select map(select empno, deptno from emps); {code}
> It will cause exception:
> {noformat}
> java.sql.SQLException: Error while executing SQL "select map(select 1, 2)":
> Unable to implement EnumerableNestedLoopJoin(condition=[true],
> joinType=[semi]): rowcount = 1.0, cumulative cost = \{13.0 rows, 3.0 cpu, 0.0
> io}, id = 72
> EnumerableCollect(field=[x]): rowcount = 1.0, cumulative cost = \{2.0 rows,
> 2.0 cpu, 0.0 io}, id = 69
> EnumerableValues(tuples=[[\\{ 1, 2 }]]): rowcount = 1.0, cumulative cost
> = \{1.0 rows, 1.0 cpu, 0.0 io}, id = 38
> EnumerableValues(tuples=[[\\{ 0 }]]): rowcount = 1.0, cumulative cost =
> \{1.0 rows, 1.0 cpu, 0.0 io}, id = 35
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:164)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:228)
> at
> org.apache.calcite.test.SqlOperatorTest$TesterImpl.check(SqlOperatorTest.java:13107)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:439)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:415)
> at
> org.apache.calcite.sql.test.SqlOperatorFixture.check(SqlOperatorFixture.java:420)
> at
> org.apache.calcite.test.SqlOperatorTest.testMapQueryConstructor(SqlOperatorTest.java:10235)
> 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
>
[jira] [Updated] (CALCITE-6060) The named parameter OFFSET in window functions should not conflicts with reserved keywords
[
https://issues.apache.org/jira/browse/CALCITE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-6060:
Labels: pull-request-available (was: )
> The named parameter OFFSET in window functions should not conflicts with
> reserved keywords
> --
>
> Key: CALCITE-6060
> URL: https://issues.apache.org/jira/browse/CALCITE-6060
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.26.0, 1.35.0
>Reporter: lincoln lee
>Priority: Major
> Labels: pull-request-available
>
> CALCITE-4171 adds support for named params in window function, but the new
> param name OFFSET conflicts with the reserved keyword, so it can't be used
> directly, users must use it with double quotes(`OFFSET`),
> which is inconvenient (especially for the built-in window functions, which I
> think shouldn't occur, actually I tend to think this is a 'bug').
> For example, a case like this:
> {code}
> @Test void testTableFunctionTumbleWithParamNames() {
> final String sql = "select *\n"
> + "from table(\n"
> + "tumble(\n"
> + " DATA => table Shipments,\n"
> + " TIMECOL => descriptor(rowtime),\n"
> + " SIZE => INTERVAL '1' MINUTE,\n"
> + " OFFSET => INTERVAL '-1' MINUTE))";
> sql(sql).ok();
> }
> {code}
> will cause SqlParseException:
> {code}
> org.apache.calcite.sql.parser.SqlParseException: Incorrect syntax near the
> keyword 'OFFSET' at line 8, column 3.
> Was expecting one of:
> "ABS" ...
> "ARRAY" ...
> "AVG" ...
> ...
> {code}
> Only `OFFSET` works.
> If we agree to rename it, I suggest replacing it with OFFSETSIZE, with the
> following considerations:
> 1. similar to window size name SIZE, the current name actually omits SIZE, so
> calling it OFFSETSIZE would be easier for users to understand
> 2. be consistent with TIMECOL without underscores
> 3. btw, we found that Azure Streaming Analytics [1] also uses the name
> OFFSETSIZE
> 1.
> https://learn.microsoft.com/en-us/stream-analytics-query/hopping-window-azure-stream-analytics#arguments
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CALCITE-6060) The named parameter OFFSET in window functions should not conflicts with reserved keywords
lincoln lee created CALCITE-6060:
Summary: The named parameter OFFSET in window functions should not
conflicts with reserved keywords
Key: CALCITE-6060
URL: https://issues.apache.org/jira/browse/CALCITE-6060
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.35.0, 1.26.0
Reporter: lincoln lee
CALCITE-4171 adds support for named params in window function, but the new
param name OFFSET conflicts with the reserved keyword, so it can't be used
directly, users must use it with double quotes(`OFFSET`),
which is inconvenient (especially for the built-in window functions, which I
think shouldn't occur, actually I tend to think this is a 'bug').
For example, a case like this:
{code}
@Test void testTableFunctionTumbleWithParamNames() {
final String sql = "select *\n"
+ "from table(\n"
+ "tumble(\n"
+ " DATA => table Shipments,\n"
+ " TIMECOL => descriptor(rowtime),\n"
+ " SIZE => INTERVAL '1' MINUTE,\n"
+ " OFFSET => INTERVAL '-1' MINUTE))";
sql(sql).ok();
}
{code}
will cause SqlParseException:
{code}
org.apache.calcite.sql.parser.SqlParseException: Incorrect syntax near the
keyword 'OFFSET' at line 8, column 3.
Was expecting one of:
"ABS" ...
"ARRAY" ...
"AVG" ...
...
{code}
Only `OFFSET` works.
If we agree to rename it, I suggest replacing it with OFFSETSIZE, with the
following considerations:
1. similar to window size name SIZE, the current name actually omits SIZE, so
calling it OFFSETSIZE would be easier for users to understand
2. be consistent with TIMECOL without underscores
3. btw, we found that Azure Streaming Analytics [1] also uses the name
OFFSETSIZE
1.
https://learn.microsoft.com/en-us/stream-analytics-query/hopping-window-azure-stream-analytics#arguments
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CALCITE-5612) Babel parser should support PostgreSQL's SET TRANSACTION command
[
https://issues.apache.org/jira/browse/CALCITE-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1047#comment-1047
]
Benchao Li commented on CALCITE-5612:
-
[~dmsysolyatin] Due to the activities on this thread, I'm removing the
fixVersion = 1.36.0, feel free to add it back when you have time to drive it
again.
> Babel parser should support PostgreSQL's SET TRANSACTION command
>
>
> Key: CALCITE-5612
> URL: https://issues.apache.org/jira/browse/CALCITE-5612
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.34.0
>Reporter: Dmitry Sysolyatin
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.36.0
>
>
> SET TRANSACTION — set the characteristics of the current transaction
> Specification [1]:
> {code}
> SET TRANSACTION transaction_mode [, ...]
> SET TRANSACTION SNAPSHOT snapshot_id
> SET SESSION CHARACTERISTICS AS TRANSACTION transaction_mode [, ...]
> where transaction_mode is one of:
> ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ
> UNCOMMITTED }
> READ WRITE | READ ONLY
> [ NOT ] DEFERRABLE
> {code}
> [1] https://www.postgresql.org/docs/current/sql-set-transaction.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CALCITE-5612) Babel parser should support PostgreSQL's SET TRANSACTION command
[
https://issues.apache.org/jira/browse/CALCITE-5612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benchao Li updated CALCITE-5612:
Fix Version/s: (was: 1.36.0)
> Babel parser should support PostgreSQL's SET TRANSACTION command
>
>
> Key: CALCITE-5612
> URL: https://issues.apache.org/jira/browse/CALCITE-5612
> Project: Calcite
> Issue Type: Bug
> Components: babel
>Affects Versions: 1.34.0
>Reporter: Dmitry Sysolyatin
>Assignee: Dmitry Sysolyatin
>Priority: Major
> Labels: pull-request-available
>
> SET TRANSACTION — set the characteristics of the current transaction
> Specification [1]:
> {code}
> SET TRANSACTION transaction_mode [, ...]
> SET TRANSACTION SNAPSHOT snapshot_id
> SET SESSION CHARACTERISTICS AS TRANSACTION transaction_mode [, ...]
> where transaction_mode is one of:
> ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ COMMITTED | READ
> UNCOMMITTED }
> READ WRITE | READ ONLY
> [ NOT ] DEFERRABLE
> {code}
> [1] https://www.postgresql.org/docs/current/sql-set-transaction.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
