The IMAP example doesn't convince me yet.
Given a GUI that select multiple values (more than ranges), the program
takes the values, feeds a GTT and does the join with the table that contains
the messages. GTTs are here already in the code base.

The discussion on where the expand the list is because we are trying to use
strings as parameters, with all the problems associated to period v/s comma,
date formats, etc. What we need is a special data type for this param. Array
comes to my mind and there's already an API for them, the only disadvantage
that it would be for arbitrary list of values, not for ranges. But arrays
already frighten several people. And when you have a GUI that accepts a
range, this is a list of values, then are ranges really critical?

But not understanding well the problem we are trying to solve, I suggest we
polish FB2.1 as sugar for app devs and then let's go back to our proposed
roadmap.
:-)

It seems I'm in the minority that sees this feature as a convenience for a
minority. The db can't do what the GUI should do. The db is the backbone,
let the application "normalize" the GUI input and whatever complex object or
have an intermediate layer that handles OO-relational conversions or use a
non relational database engine instead.

C.