On Tue, Jan 11, 2011 at 7:14 AM, Noah Misch <noah@leadboat.com> wrote:
>> I have a concern that by making the ALTER TABLE more complex that we
>> might not be able to easily tell if a rewrite happens, or not.
>>
>> Perhaps we should add a WITHOUT REWRITE clause? That would allow a user
>> to specify that they do not wish a rewrite, so if the AT requires them
>> to have one it would then fail.
>
> These changes do make it harder to guess how much work the ALTER TABLE will do.
> Indeed, about 1/4 of my own guesses prior to writing were wrong. Something like
> WITHOUT REWRITE might be the way to go, though there are more questions: if it
> does not rewrite, does it scan the table? Which indexes, if any, does it
> rebuild? Which foreign key constraints, if any, does it recheck? With patch 0,
> you can answer all these questions by enabling DEBUG1 messages and trying the
> command on your test system. For this reason, I did consider adding a VERBOSE
> clause to show those messages at DETAIL, rather than unconditionally showing
> them at DEBUG1. In any case, if a WITHOUT REWRITE like you describe covers the
> important question, it's certainly easy enough to implement.
I'm doubtful that it's worth complicating the parser logic. Our DDL
is transactional, so someone can always begin a transaction, increase
client_min_messages, and then look at the output from these added
debug messages to see what is happening. It should be clear within a
second or two if it's not what is wanted, and they can just hit ^C.
> True. At least we could completely document the lock choices on the ALTER TABLE
> reference page. The no-rewrite cases are defined at arms length from ALTER
> TABLE, and users can define their own, so it's a tougher fit.
I don't think it's prohibitively, tough, though, and I think it would
be very valuable. We may have to scratch our heads over exactly where
to put the information, but we can figure out something that works.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
