On Fri, Oct 3, 2014 at 12:07 AM, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 10/2/14, 2:43 PM, Josh Berkus wrote: >>> >>> >Questions: >>> > >>> > 1. Do you agree that a systematic way to report what a DDL command (or >>> > script, or transaction) is going to do on your production database >>> > is a feature we should provide to our growing user base? >> >> Yes. > > +1 >>> >>> > 2. What do you think such a feature should look like? >> >> As with others, I think EXPLAIN is a good way to do this without adding >> a keyword. So you'd do: >> >> EXPLAIN >> ALTER TABLE .... > > I'm thinking it would be better to have something you could set at a session > level, so you don't have to stick EXPLAIN in front of all your DDL. > > As for the dry-run idea, I don't think that's really necessary. I've never > seen anyone serious that doesn't have a development environment, which is > where you would simply deploy the real DDL using "verbose" mode and see what > the underlying commands actually do.
Well, the thing that's difficult to reproduce on a development environment, is the locking issues. It may run perfect on an idle system, only to lock up forever (or unacceptably long) on a busy one. That is, probably, one concern that can be attacked relatively cheaply with some clever locking / cancelling logic. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers