We don't have any good support for the more common operators like != < > <= etc... besides inline sql, we should come up with proper support for those before we add BETWEEN.

Also, we can't support those syntaxes. 'colname' => array( [...] ) is already used to create a 'colname IN (...)'.

We'll need to come up with a new way of writing queries.

We could make a "real" query building object:

DBQuery::conds()

->column('colname')->eq($foo)
->column('colname')->in($arr)
->column('colname')->like("{0}%", $foo) // perhaps something better, but I didn't like the idea of a pile more buildLike-like stuff
->column('colname')->between(1,5)
->column('colname')->compare('>=', 3)

Then again, what I really want myself is abstraction that kills the need to depend heavily on database structure.

(In reply to comment #1)

We don't have any good support for the more common operators like != < > <=
etc... besides inline sql, we should come up with proper support for those
before we add BETWEEN.

Maybe that's a different bug to log? ;)

But you're right, it'd be nicer to be able to support the numerous "basic" operations

See also T210206: Deprecate raw SQL conditions for IDatabase methods (select, insert, etc.).

I'm not convinced we should do this. It made sense when we didn't have a generalized expression builder but turning a between into a chained and condition is a piece of cake now.