From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: extensible enum types |
Date: | 2010-06-18 16:35:45 |
Message-ID: | A9935587-F377-427F-AAF3-A5BBEBA83B17@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Jun 18, 2010, at 9:07 AM, Robert Haas wrote:
>> Then set the
>> first value at 8 * p, then next at 9* p and so on. This is designed to
>> allow more space to add labels at the beginning and end of the list, where
>> this is more likely. Adding a label would be a matter of finding the labels
>> adjacent to the position where we want to add the new label, and placing it
>> half way between them, possibly with special rules for the list ends. If we
>> want to add the label between two labels having values n and n+1 the
>> addition would fail.
>
> I like the idea of being able to modify enums on the fly, but I'm
> skeptical of an implementation that won't always work. Maybe it's
> still better than what we have now, but it seems grotty.
Yes, other than that I fully endorse the idea. What's the likelihood of a failure? And would the position of the new label (represented by its internal number) be predictive? IOW, would updating the same varenumtype in two databases (or on two servers) yield the same underlying positional value?
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2010-06-18 16:36:23 | Re: extensible enum types |
Previous Message | Andrew Dunstan | 2010-06-18 16:34:35 | Re: extensible enum types |