-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.eq_any(ARRAY(subselect))
and .eq_any(ARRAY[..., ...])
support
#4353
Conversation
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
diesel/src/pg/expression/array.rs
Outdated
/// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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`
array(...)
function.eq_any(ARRAY(subselect))
support
6912d7b
to
6e4d7b7
Compare
b346e22
to
18c44a5
Compare
.eq_any(ARRAY(subselect))
support.eq_any(ARRAY(subselect))
and .eq_any(ARRAY[..., ...])
support
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good for me 👍
/// | ||
/// It has several quirks: | ||
/// - `All<Expr: Expression<SqlType = Array<ST>>>` pretends to be an expression of type `ST`, | ||
/// but it's in fact some custom that can really be only used in combination with the `=` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically it can also be used with different operators, e.g. like
, which is something that we still not support without the deprecated functions
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
AsExpressionList
trait 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.)