Tom Lane wrote:
Bruce Momjian <br...@momjian.us> writes:
Well, we don't need the enum value to map into the entire oid range.
Can't we just add one to the top-most value and see if there is a
conflict?
If you don't use the OID counter to generate the new value, you're going
to have problems with race conditions. There's also that small chance
that there is no free value before 2^32.
The bottom line here is not wanting a feature that "usually" works but
fails once in awhile on the basis of conditions the user can't control.
Yeah, what I'm now hoping to be able to do, following good suggestions
from Tom, is to provide a way to get virtually no degradation in bulk
comparison performance in the common case where any additions have been
made at the end of the list with no oid wraparound, and acceptable
performance otherwise, but provide for an ability to add new values at
arbitrary places in the ordering, with no limit.
If we can do that why would we want less?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
