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