From: | Yeb Havinga <yebhavinga(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: extended operator classes vs. type interfaces |
Date: | 2010-04-09 15:07:43 |
Message-ID: | 4BBF42BF.1010502@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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.
regards
Yeb Havinga
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-04-09 15:08:30 | Re: GSOC PostgreSQL partitioning issue |
Previous Message | Yeb Havinga | 2010-04-09 14:53:19 | Re: extended operator classes vs. type interfaces |