Robert Haas wrote: > On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga <yebhavi...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers