Description of the change
.limit and .offset can now accept any valid Diesel expression, not just i64. This can only be used with the PostgreSQL backend, MySQL and SQLite continue to only accept i64 values.
Why is this needed?
PostgreSQL allows any expression that doens’t depend on the results of the query to appear in limit or offset clauses. The signature of LimitDsl and OffsetDsl restricts us to only accepting i64 values.
Why can’t this have a deprecation cycle?
This requires changing the signature of a trait. The only way we can deprecate this is to introduce a new trait or method, deprecating the old one. That would be overkill here, since this change will only affect implementors not callers.
Expected user impact
Nearly zero. The only way applications will be affected is if they were relying on the call to .offset for type inference purposes. e.g. .offset(str.parse().unwrap()) will require an explicit type annotation.
Any implementors of LimitDsl and OffsetDsl will need to change their signature to the generic form (unlikely to exist).
Any custom backends will need to explicitly add a trait impl to state what they accept.
Migration strategy
Affected applications can explicitly state that the value being passed to .offset is an i64. No other changes are required on their end. This is forwards compatible.
Implementors of OffsetDsl will need to change their signature from i64 to impl AsExpression<BigInt>. OffsetDsl will also be generic over the argument type. This is not forwards compatible.
Any custom backends will need to add an impl stating what they can handle in offset/limit clauses. This will probably look like one of these two impls:
impl<T> ValidOffsetClause<Bound<BigInt, T>> for DB {}
or
impl<T> ValidOffsetClause<T> for DB
where
T: SelectableExpression<()>,
{}
We can make this forwards compatible by adding these traits before 2.0, and only using them after 2.0.