| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: WIP: extensible enums |
| Date: | 2010-10-18 17:15:16 |
| Message-ID: | 4CBC80A4.4080508@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10/18/2010 10:52 AM, Tom Lane wrote:
> We could possibly deal with enum types that follow the existing
> convention if we made the cache entry hold a list of all the original,
> known-to-be-sorted OIDs. (This could be reasonably compact and cheap to
> probe if it were represented as a starting OID and a Bitmapset of delta
> values, since we can assume that the initial set of OIDs is pretty close
> together.)
How are we going to know what those are?
We could keep track of the beginning and end of the original range maybe
and refuse to create any new enum values for the type inside that range.
That might make binary upgrade a bit ugly, but it's probably manageable
even so.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Cramer | 2010-10-18 17:24:58 | Re: create tablespace fails silently, or succeeds improperly |
| Previous Message | Tom Lane | 2010-10-18 17:12:10 | Re: Floating-point timestamps versus Range Types |