Re: extended operator classes vs. type interfaces

On Fri, Apr 9, 2010 at 4:01 PM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
> Robert Haas wrote:
>>
>> On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
>>
>>>
>>> .. I now see the example of different ranges in your original mail with
>>> different unit increments. Making that more general so there could be
>>> continuous and discrete ranges and for the latter, what would the
>>> increment
>>> be.. OTOH is a range of integers with increment x a different type from
>>> range of integers with increment y, if x<>y? Maybe the increment step and
>>> continuous/discrete could be typmods.
>>>
>>
>> Nope, not enough bits available there.  This is fundamentally why the
>> typid/typmod system is so broken - representing a type as a fixed size
>> object is extremely limiting.  A fixed size object that MUST consist
>> of a 32-bit unsigned OID and a 32-bit signed integer is even more
>> limiting.  Fortunately, we don't need to solve that problem in order
>> to implement range types: we can just have people explicitly create
>> the ones they need.  This will, for example, avoid creating ranges
>> over every composite type that springs into existence because a table
>> is created, even though in most cases a fairly well-defined range type
>> could be constructed.
>>
>
> Ok, no typmod, not default extra types for base types, but the concept of an
> still there is one aspect of ranges (may I say intervals?) of 'things' is
> something generic, and code to handle intervals of things could be shared
> between datatype implementations. A way to have generic support without
> automatic new types could be with something that looks like:
>
> What about
> CREATE TYPE ivl_int AS INTERVAL OF integer;
>
> SELECT '[1;2]'::ivl_int;
> etc

Yeah, that's how it has to work, I think.

...Robert