feat[expr-common]: support regex and LIKE coercion on REE and Dict value types that require an extra coercion step#21924
Conversation
| @@ -1767,7 +1767,7 @@ pub fn like_coercion(lhs_type: &DataType, rhs_type: &DataType) -> Option<DataTyp | |||
| string_coercion(lhs_type, rhs_type) | |||
| .or_else(|| binary_to_string_coercion(lhs_type, rhs_type)) | |||
| .or_else(|| dictionary_coercion(lhs_type, rhs_type, false, string_coercion)) | |||
There was a problem hiding this comment.
Why does dictionary stay as string_coercion whilst ree is the one that changes?
There was a problem hiding this comment.
I think this should also be like_coercion. Dictionary probably suffers from the same issue but it's a little more rare to find a dict of a complex type that resolves to a string (e.g. Dict<Ree> doesn't make much sense I believe you'd always prefer Ree). Happy to fix it, wasn't sure whether to keep this PR ree only.
There was a problem hiding this comment.
Actually can't seem to construct Dict<REE> but Dict<Binary> is an example that produces a failure. Updated the PR.
04bbf6a to
ba48440
Compare
|
The failures seem to be flakes. |
Jefffrey
left a comment
There was a problem hiding this comment.
Should be able to resolve CI errors by merging up from main
(Can ignore breaking changes CI check regardless)
ba48440 to
115e29b
Compare
The coerce_fn applied to REE values needs to be the higher-level coerce function so that any REE value can be coerced (not just primitive types). Signed-off-by: Alfonso Subiotto Marques <alfonso.subiotto@polarsignals.com>
And others that need an extra coercion step before string coercion. Signed-off-by: Alfonso Subiotto Marques <alfonso.subiotto@polarsignals.com>
115e29b to
2d1b428
Compare
|
Rebased |
|
Thanks @asubiotto |
The coerce_fn applied to REE values needs to be the higher-level coerce function so that any REE value can be coerced (not just primitive types).
Which issue does this PR close?
Rationale for this change
Queries were failing
What changes are included in this PR?
Correct unwrapping of REE values for regex/LIKE coercion
Are these changes tested?
Yes, with slt tests.
Are there any user-facing changes?
Queries that would previously error now pass.