Re: Range Types, constructors, and the type system

On Jun29, 2011, at 17:41 , Jeff Davis wrote:
>> Is it? That's actually too bad, since I kinda like it. But anyway,
>> if that's a concern it could also be
>> range_bounds(ARRAY[1,2]::int8range, '(]')
>
> What type would the result of that be? What value?

ARRAY[1,2]::int8range would return an int8range instance representing
the range [1,2] (i.e. the set of values {1,2}). range_bounds would then
modify the left bound to be exclusive, and thus return the int8range
(1,2] (i.e. the set of values {2}). range_bounds would have the signature
range_bounds(anyrange) returns anyrange.

I do think we'll probably want to have functions to modify the boundary
type (open or closed) anyway, so it wouldn't be that huge of a deal if
the range constructor didn't let you specify them.

Empty ranges would be constructed by
ARRAY[]::int8range
(Hm, ok, now I'm cheating... Currently you'd need to write
ARRAY[]::int8[]::int8range, but fixing that only needs a few lines
in the transformExpression* function that makes ARRAY[]::int8[] work).

>>> * 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.
>>
>> I believe it alleviates the gravest problems of casting back and forth
>> to text. It doesn't have quoting issues and it doesn't potentially lose
>> information.
>
> I think it still circumvents the type system to a degree. We're just
> putting stuff in an array with no intention of really using it that way.

Well, arrays are containers, and we need two values to construct a range,
so putting them into a container first and then creating the range from that
doesn't seem so bad to me. We do use the full set of features that arrays
provide, since we only ever expect zero, one or two entries. But I don't
think this is different from functions who only support single-dimensional
arrays - they too choose to use only a subset of the features set of arrays.

>> In any case, I wouldn't expect this to *stay* the only way to construct
>> a range forever. But I does have it's virtues for a first incarnation of
>> range type, I believe, mostly because it's completely unintrusive and
>> won't cause any backwards-compatbility headaches in the future
>
> I'm not sure that your overloading of arrays is completely immune from
> backwards-compatibility problems, should we decide to change it later.
>
> But regardless, we have quite a lot of time to make a decision before
> 9.2 is released; so let's do it once and do it right.
>
>> I fear that the intermediate type will turn out to be quite intrusive,
>> at least if we try to handle all the corner cases and loose ends. And if
>> we don't, I'm concerned that we're painting ourselves into a corner here...
>
> Can you expand on some of the corner-cases and loose ends you're
> concerned about? Does marking it as a pseudotype and making the IO
> functions throw exceptions handle them?

Hm, I guess. I'm sill no huge fan of RANGEINPUT, but if we prevent
it from being used as a column type and from being used as an argument
type, then I guess it's workable...

Btw, what happened to the idea of making RANGE(...) a special syntactic
construct instead of a normal function call? Did we discard that for its
intrusiveness, or were there other reasons?

best regards,
Florian Pflug