On Sat, Apr 26, 2008 at 12:10 AM, Brendan Jurd <[EMAIL PROTECTED]> wrote: > Has anyone had a close look at how hard it would be allow just the > "add to the end" capability?
If the OIDs haven't wrapped around since the enum was created, it's trivial. If they have, well someone with more OID-fu than me will have to explain what we'd have to do to guarantee getting a new OID higher than a certain value. And if your highest enum oid happens to be 4^32-1, you're in trouble :). I wonder if it's worth revisiting the decision to save enums on disk as oids. The very first idea that I had was to have an enum value as the combination of both an enum id and the ordinal value. We would presumably make both say 16bits so we could still be be passed by value. This would restrict us to 2^16 enum types per database and 2^16 values per type, but if anyone is getting within an order of magnitude of either limit I'd be very interested in seeing what they're doing. The nice thing about the above approach is that we could space out the ordinal values so as to allow people to insert a fair number of extra values before forcing a rewrite of the table. The only thing we really couldn't handle that way would be reordering - we'd need an extra layer of indirection for that, which would have some performance penalties. None of the standard operators for enums require a syscache lookup currently, only I/O does, Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
