Re: extended operator classes vs. type interfaces

On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
>
>> From the implementers perspective, IMHO an extra catalog entry in pg_type
>> is not bad on its own, you would have one anyway if the range type was
>> explicitly programmed. About different kinds of range types - I would not
>> know how to 'promote' integer into anything else but just one kind of 'range
>> of integer' type. So the number of extra pg_types would be more like
>> O(number of linear ordered base types).
>
> .. 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.

...Robert