Andrew Dunstan <andrew@dunslane.net> writes:
> Alvaro Herrera wrote:
>> Another alternative would be internally creating a different temporary
>> enum, rewriting the tables one by one each on its own transaction, and
>> finish by dropping the original enum and renaming the temporary one.
>> This solves the deadlock problem.

> What happens when someone tries to join two of the tables, one that has
> been converted and one that hasn't? You might not have deadlock, but you
> won't have type integrity either, ISTM.

Not to mention the mess you'll be left with if the process fails after
converting some of the tables.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

> I don't understand this if it's calling option 2 the monolithic
> implementation. I was intending that the values be permanent tokens if
> you like, so that ZERO rewriting would be required for any types of
> modification. So I don't see where locking comes in. I don't want
> rewriting either.

I think you are not considering existing btree indexes here
(for the reordering case) ?

So +1 on a solution that has naturally sorting keys (e.g. your 1).

Andreas

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Apr 28, 2008 at 2:24 PM, Zeugswetter Andreas OSB SD
<Andreas.Zeugswetter@s-itsolutions.at> wrote:
> I think you are not considering existing btree indexes here
> (for the reordering case) ?

You're quite right, I had not considered existing indexes. There's no
easy way to deal with that other than rebuilding them.

I *still* think someone with a big table would prefer to drop/create
their indexes rather than go through a nasty ALTER COLUMN which would
have the seemingly much worse outcome of rebuilding their whole table
AND any indexes. But whatever - I'll implement option 1 and submit it,
as a marked improvement over the status quo. If I can make option 2
work fast enough I'll consider submitting it as a feature improvement
thereafter, but given the general consensus for option 1 I'm not
pushing option 2 much any more.

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