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