Skip to content

UnionExec can panic when stale equivalence constants are rewritten after projection #23374

Description

@xudong963

Describe the bug

UnionExec::try_new can panic while computing equivalence properties if stale constant metadata is carried across a projection and then rewritten to the union output schema.

For example, a filter such as ticker = 'ESU6' can leave a uniform string constant in equivalence properties. If a parent projection drops ticker, union property schema rewriting can later see the remaining column slot as a timestamp column and attempt to cast 'ESU6' to Timestamp, which fails during planning.

The issue is in optimizer metadata handling: an unrepresentable constant after schema rewrite should be discarded rather than failing query planning.

To Reproduce

The reduced shape is:

UNION ALL over inputs with equivalence properties
filter leaves a constant such as ticker = 'ESU6'
parent projection drops ticker
union equivalence properties are rewritten to the projected schema

Expected behavior

Planning should not panic. Stale/unrepresentable equivalence constant metadata should be dropped during schema rewrite.

Additional context

The same path currently goes through EquivalenceProperties::with_new_schema, where the constant value is cast to the rewritten expression type, and UnionExec::try_new, which unwraps property computation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions