On Fri, Oct 3, 2014 at 12:07 AM, Jim Nasby <Jim.Nasby@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.
