From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: extensible enum types |
Date: | 2010-06-18 16:56:14 |
Message-ID: | 4C1BA52E.6060809@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
David E. Wheeler wrote:
> What's the likelihood of a failure?
Constructing a failure case would be simple. In practice, I suspect it
would be very low.
> 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?
>
>
>
The algorithm I outlined is deterministic, so the same sequence of
operations on the type would yield the same set of values on the
low-order 16 bits. But that doesn't mean they would have the same high
order 16 bits. That would depend on the history of the system. But more
importantly, why do you care? the stored value is an implementation
artefact that should be totally invisible to users. There would be no
guarantee of the same underlying values on dump/reload either, just as
there is not now for enums.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-06-18 16:59:10 | Re: extensible enum types |
Previous Message | Tom Lane | 2010-06-18 16:45:10 | Re: extensible enum types |