On Fri, Apr 25, 2008 at 11:57 PM, Alvaro Herrera
<alvherre@[EMAIL PROTECTED]
> wrote:
> We already sup****t 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@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
