Tom Dunstan wrote:
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.
Or else we just error out in such cases. As Tom Lane suggests, rewriting has some nasty deadlock possibilities.
You always have the option of creating a new enum type and moving each affected column to that type.
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.
Being able simply to order by the oid value is fast. That's one of the current benefits. So I think we'd need some benchmarking to show that this wouldn't slow things down.
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
