.eq_any(ARRAY(subselect)) and .eq_any(ARRAY[..., ...]) support
#4353
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit 1fe73f5.
auto_type will work only if ST is explicitly specified when calling array, which looks reasonable
Unfortunately this keeps talking about AsExpressionList instead of IntoArrayExpression :( Hopefully Rust ends up fixing this
Ten0
commented
Nov 20, 2024
diesel/src/pg/expression/array.rs
Outdated
Comment on lines
82
to
93
| /// Implement as a no-op for things that were already arrays (that is, don't wrap in ARRAY[]). | ||
| impl<ST, T> IntoArrayExpression<ST> for T | ||
| where | ||
| T: AsExpressionList<ST>, | ||
| T: AsExpression<sql_types::Array<ST>>, | ||
| ST: SqlType + TypedExpressionType + 'static, | ||
| { | ||
| ArrayLiteral { | ||
| elements: elements.as_expression_list(), | ||
| _marker: PhantomData, | ||
| type ArrayExpression = <T as AsExpression<sql_types::Array<ST>>>::Expression; | ||
|
|
||
| fn into_array_expression(self) -> Self::ArrayExpression { | ||
| <T as AsExpression<sql_types::Array<ST>>>::as_expression(self) | ||
| } | ||
| } |
There was a problem hiding this comment.
I'm not sure if we should have this impl. Maybe not, if we want to map as close as SQL as possible and forbid writing array(array_expr) for something that's actually going to get serialized as just array_expr.
It seems easier to add later on than to remove.
On the other hand it seems unlikely to be hurtful.
This removes the fake Expression implementation for `Many`, instead relying on an `InExpression` trait (which replaces `MaybeEmpty`) that represents that that query fragment is valid for use inside `IN` or `= ANY`
Ten0
changed the title
array(...) function.eq_any(ARRAY(subselect)) support
Ten0
commented
Nov 20, 2024
Conflicts: diesel/src/expression/array_comparison.rs
Ten0
force-pushed
the
array_subselect
branch
from
6912d7b
to
6e4d7b7
Compare
Ten0
force-pushed
the
array_subselect
branch
from
b346e22
to
18c44a5
Compare
Ten0
changed the title
.eq_any(ARRAY(subselect)) support.eq_any(ARRAY(subselect)) and .eq_any(ARRAY[..., ...]) support
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As underlined here, there are cases where
= ANY(array)does not behave the same as= ANY(subquery), so it may be useful to explicitly convert a subquery into an array.This PR allows doing this.
It adds support for:
array(subselect)array(...)in.eq_any(...)and.ne_all(...)expressionsIt's technically a breaking change, but only to the extent to which people implemented the
AsExpressionListtrait manually, or wrote new query fragments that use this as bound, which seems unlikely enough that this can probably be released. (That's only a marker trait for usage ofarray(...)in its current somewhat-limited version.)