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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
