[
https://issues.apache.org/jira/browse/PHOENIX-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kyle Purtell updated PHOENIX-8052:
-----------------------------------------
Summary: ALL and ANY array comparisons are confused (was: Universal (ALL)
and existential (ANY) array comparisons are confused)
> ALL and ANY array comparisons are confused
> ------------------------------------------
>
> Key: PHOENIX-8052
> URL: https://issues.apache.org/jira/browse/PHOENIX-8052
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Affects Versions: 5.3.2
> Reporter: Andrew Kyle Purtell
> Assignee: Andrew Kyle Purtell
> Priority: Major
> Fix For: 5.4.0, 5.3.3
>
>
> Implementation of universal (ALL) and existential (ANY) array comparisons
> have a common inheritance differing only in concrete node type. Because AST
> cloning relies on visitor traversal, the inherited traversal hook caused
> {{CloneExpressionVisitor}} to dispatch to the base visitor method, mistakenly
> reconstructing cloned ALL expressions as ANY comparisons.
> This surfaces whenever the query engine duplicates expressions, such as for
> server side array, JSON, and BSON projection rewrites; and for projecting via
> {{RowProjector}} to isolate per-invocation, non-deterministic functions (such
> as RAND()) across execution threads
> Conditions like {{= ALL(...)}} or {{< ALL(...)}} silently collapsed into
> existential (ANY) semantics during query compilation and execution.
> Examples:
> {noformat}
> SELECT ARR1[1] = ALL(ARR2) FROM T
> UPSERT INTO T2 SELECT ID, FLOOR(RAND() * 3) < ALL(ARR) FROM T1
> {noformat}
> The fix is for the cloning visitor to preserve the distinction between the
> subtypes.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
