On Fri, Apr 9, 2010 at 4:01 PM, Yeb Havinga <yebhavi...@gmail.com> wrote: > Robert Haas wrote: >> >> On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga <yebhavi...@gmail.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
Yeah, that's how it has to work, I think. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers