Re: Range Types, constructors, and the type system

On Jun28, 2011, at 05:42 , Jeff Davis wrote:
> On Mon, 2011-06-27 at 14:50 -0400, Robert Haas wrote:
>> Couldn't we also do neither of these things? I mean, presumably
>> '[1,10]'::int8range had better work.
>
> I think that if we combine this idea with Florian's "PAIR" suggestion
> here:
> http://archives.postgresql.org/message-id/AD4FC75D-DB99-48ED-9082-52EE3A4D74A6@phlo.org
>
> then I think we have a solution.
>
> If we add a type RANGEINPUT that is not a pseudotype, we can use that as
> an intermediate type that is returned by range constructors. Then, we
> add casts from RANGEINPUT to each range type. That would allow
> range(1,2)::int8range
> to work without changing the type system around, because range() would
> have the signature:
> range(ANYELEMENT, ANYELEMENT) -> RANGEINPUT
> and then the cast would change it into an int8range. But we only need
> the one cast per range type, and we can also support all of the other
> kinds of constructors like:
> range_cc(ANYELEMENT, ANYELEMENT) -> RANGEINPUT
> range_linf_c(ANYELEMENT) -> RANGEINPUT
> without additional hassle.

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.

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]'

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

best regards,
Florian Pflug