On Sat, Apr 26, 2008 at 2:07 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > > 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. > > I seem to remember that we discussed that and rejected it, but I don't > remember the reasoning...
I don't think there was any terribly strong objection. IIRC I originally proposed trying to fit everything into 2 bytes, you objected to that as "unnecessary bit-shaving" and proposed 8 bytes, I didn't want to give up pass-by-value, plus my initial pg_enum design was rather denormalized - the current solution was a compromise that fixed that and kept everyone happy. :) But we didn't really consider updates too carefully. Maybe it was just a bit too cute a solution. So two alternative proposals, both with a 2 byte "enum id" and a 2 byte "value": 1 - We space the values out as evenly as we can across the 65000ish range and allow people to delete, insert and append, but not reorder. If they do the above gratuitously we might have to do a rewrite, but they'll have to get fairly busy to do it. Rewrite would be required for reorderings. 2- We totally give up the idea of storing a value on disk that is directly comparable (other than equality), and simply number from zero up, using that number to index into an array (or use as syscache key or whatever) containing the real ordering information. We can then reorder or do any other operations to our heart's content. I'm actually favouring option 2 - I think it can be done in such a way as to not be much of an overhead compared to the status quo, and you know that if we don't implement proper reordering now, someone will ask for it, and we'll be having this discussion at a similar time after 8.4 goes out. I'm happy to work on a patch for this if it meets general approval. 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
