Re: extended operator classes vs. type interfaces

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

regards,
Yeb Havinga