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