On Mon, 2009-12-14 at 13:32 -0500, Tom Lane wrote:
> Well, if the intention is to invent two different kinds of ranges, with
> different operators, for continuous and discrete data types, then fine.
Originally I thought most of the use cases were workable as discrete
ranges. If people want continuous ranges, that's certainly doable by
using a slightly different API.
> But the original post suggested no such thing, and provided (unworkable)
> examples suggesting that the intent was to force every type to be
> treated as discrete whether that makes any sense or not.
I agree, we shouldn't say we support continuous types, but force them to
be treated like discrete types.
> The main question I would have is how to tell whether the underlying
> type is really discrete.
We can ask the user to provide a prior() and next() function, and if
they aren't provided, we assume it's continuous.
Also, this range mechanism may be useful to get the meaningful operators
for a range type. For instance, for a range join (e.g. a temporal join),
we could recognize the && as "overlaps" and then find the "strictly left
of" operator if we wanted to do a range merge join. This might be
cleaner than the previous idea to mark operator families as conforming
to a certain convention for strategy numbers.
> (Also, stuff like strings simply doesn't have any sane concept of a
> unique next or previous value. I think the number of types that are
> really discrete in this sense is very small, like maybe just ints and
> enums.)
I think "countable" is a more accurate word than "discrete". Strings are
discrete but not countable.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
