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