"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> On Sat, Apr 26, 2008 at 6:33 AM, Tom Dunstan wrote:
>> 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.
> That would be okay too, but I think I'd prefer proceeding with the
> rewrite after emitting a NOTICE. If the db admin decides not to go
> ahead, or wait to do it after hours, she can always hit ^C, right?
The more I think about it, the less I think that we want to support such
a feature at all. Consider that it'd require taking a fairly strong
lock (surely at least locking out other writers) on every table using
the enum, in who-knows-what order. The odds of completing without
deadlock seem to be right about nil.
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
