From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: extended operator classes vs. type interfaces |
Date: | 2010-04-09 15:14:26 |
Message-ID: | w2o603c8f071004090814o641e6ed1i70d117f76b442823@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga <yebhavinga(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Necati Batur | 2010-04-09 15:25:06 | Gsoc XQuery |
Previous Message | Alvaro Herrera | 2010-04-09 15:08:30 | Re: GSOC PostgreSQL partitioning issue |