On Fri, Apr 25, 2008 at 11:57 PM, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > We already support rewriting tables ... (albeit only one at a time, I > admit. Doing it for more than one can cause deadlocks). > > Still, if the user wants to pay the cost, why should we prohibit it?
One scenario I'm not happy about is this: the friendly db admin has happily added an extra value to the end before and the operation has been a snap - no rewriting required. But this time either a) oid wraparound has occurred, b) she's inserted one or c) she's reordered them. Bam - we start rewriting the entire database. That's not the kind of surprise I like giving people, and the current situation of either don't allow updates at all, or the alternative to surprises of always rewrite everything seem pretty deficient. And I don't want to only allow updates if they won't cause a rewrite, it's nondeterministic. I've already suggested some alternatives in the reply to Brendan that would solve some of this, but I suppose another gross-seeming way to stop surprise rewrites would be to never do one unless given a FORCE REWRITE clause on the ALTER statement or something like that, and fail if a rewrite is required not specified. > So the user can create a new enum with the options he > wants, then rewrite his tables one by one, then drop the original. They can pretty much do this now, they just need to define an implicit cast I think. 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
