On Tue, Jan 11, 2011 at 7:14 AM, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
