Doug Chamberlin wrote:

>
>> Then, each item are separated and evaluated as:
>> X IN ('01-01-2006', '05-15-2006') OR (X BETWEEN '02-27-2006' AND
>> '03-01-2006')
>
> Ok, I guess I didn't get it because I have always thought of the
> IN(x,y,z,...) construct to represent an *unordered* set of values of any
> type. Your syntax, and LIST construct (passable as a single parameter),
> would only be usable when the list of values is to be interpreted as an
> ordered list that can be expressed with an equivalent combination of
> IN(x,y,z..) and BETWEEN(x and y).

Good point. For me, this is yet another reason to not mixing the things.
If the engine needs the list to be an ordered one (in order to optimize
ranges properly), it brings more requirements to the application side,
thus decreasing the feature's value.

Personally, I don't like both proposals, as I see a number of
workarounds. But I know that some people want the IN predicate to take a
string with delimited items and some others dream about the unlimited IN
(1, 2, ...) implementation. So I could agree with the first part of the
idea, provided that we see enough demand from others. However, I'm still
not convinced about the ranges idea.


Dmitry