Closed Ten0 closed 1 hour ago
I imagine most uses of eq_any are actually to filter, and because filter accepts both they will keep compiling.
We have 500 uses of eq_any
in our codebase and all of those are .filter
.
I personally would expect that this won't cause much breakage for using a.eq_any(b)
outside of filter. I see more potential for breakage by having some functions that return Box<dyn BoxableExpression<SqlType = Bool>>
which contains such an IN
expression and suddenly turn to Nullable<Bool>
due to this change.
That written: I still would see that as bugfix and therefore allowed breakage, but we should have an explicit changelog entry for this, so that it does not get lost before the next update.
PG returns null for IN expressions if LHS is null or if result depends on a NULL inner element of the array. The return value of the IN & co expressions was incorrectly represented as non-nullable in this case.
While this is a breaking change, it should probably also be considered a bugfix, so we should be able to release it.