On Tue, Jan 11, 2011 at 12:37:28PM +0000, Simon Riggs wrote: > On Tue, 2011-01-11 at 07:14 -0500, Noah Misch wrote: > > > 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. > > Trouble is, only superusers can set DEBUG1.
Setting client_min_messages in one's session works, as does "ALTER ROLE myself SET client_min_messages = debug1". Still, indeed, DEBUG1 is not the usual place to send a user for information. > You're right, its more complex than I made out, though that strengthens > the feeling that we need a way to check what it does before it does it, > or a way to limit your expectations. Ideally that would be a > programmatic way, so that pgAdmin et al can issue a warning. > > Given your thoughts above, my preference would be for > EXPLAIN ALTER TABLE to describe the actions that will take place. That does seem like the best UI. Offhand, I would guess that's a project larger than the patch series I have here. We'd need to restructure ALTER TABLE into clear planning and execution stages, if not use the actual planner and executor. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers