Robert Haas wrote:
> On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga <yebhavinga@gmail.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.
You mean the typmod system we developed 13 years ago needs updating?
Seems unlikely. ;-)
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
