Re: Range Types, constructors, and the type system

On Tue, 2011-06-28 at 22:20 +0200, Florian Pflug wrote:
> Hm, so RANGEINPUT would actually be what was previously discussed as
> the "range as a pair of bounds" definition, as opposed to the
> "range as a set of values" definition. So essentially we'd add a
> second concept of what a "range" is to work around the range input
> troubles.
>
> I believe if we go that route we should make RANGEINPUT a full-blown
> type, having "pair of bound" semantics. Adding a lobotomized version
> just for the sake of range input feels a bit like a kludge to me.

I think David Wheeler was trying to make a similar point, but I'm still
not convinced.

It's not a pair, because it can be made up of 0, 1, or 2 scalar values
(unless you count infinity as one of those values, in which case 0 or
2). And without ordering, it's not clear that those values are really
"bounds".

The type needs to:
* represent two values, either of which might be a special infinite
value
* represent the value "empty"
* represent inclusivity/exclusivity of both values

and those things seem fairly specific to ranges, so I don't really see
what other use we'd have for such a type. But I'm open to suggestion.

I don't think that having an extra type around is so bad. It solves a
lot of problems, and doesn't seem like it would get in the way. And it's
only for the construction of ranges out of scalars, which seems like the
most natural place where a cast might be required (similar to casting an
unknown literal, which is fairly common).

> Alternatively, we could replace RANGEINPUT simply with ANYARRAY,
> and add functions ANYRANGE->ANYRANGE which allow specifying the
> bound operator (<, <= respectively >,>=) after construction.
>
> So you'd write (using the functions-as-fields syntax I believe
> we support)
> (ARRAY[1,2]::int8range).left_open.right_closed for '(1,2]'
> and
> ARRAY[NULL,2]::int8range for '[-inf,2]'

I think we can rule this one out:
* The functions-as-fields syntax is all but deprecated (or should be)
* That's hardly a readability improvement
* It still suffers similar problems as casting back and forth to text:
ANYARRAY is too general, doesn't really take advantage of the type
system, and not a great fit anyway.

> All assuming that modifying the type system to support polymorphic
> type resolution based on the return type is out of the question... ;-)

It's still not out of the question, but I thought that the intermediate
type would be a less-intrusive alternative (and Robert seemed concerned
about how intrusive it was).

There also might be a little more effort educating users if we selected
the function based on the return type, because they might think that
casting the inputs explicitly would be enough to get it to pick the
right function. If it were a new syntax like RANGE[]::int8range, then I
think it would be easier to understand.

Regards,
Jeff Davis