Re: DDL Damage Assessment

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: DDL Damage Assessment
Дата
Msg-id 20141002194044.GV28859@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: DDL Damage Assessment  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: DDL Damage Assessment
Re: DDL Damage Assessment
Список pgsql-hackers
* Joshua D. Drake (jd@commandprompt.com) wrote:
> >  2. What do you think such a feature should look like?
>
> I liked the other post that said: EXPLAIN <ALTER TABLE> or whatever.
> Heck it could even be useful to have EXPLAIN ANALZYE <ALTER TABLE>
> in case people want to run it on staging/test/dev environments to
> judge impact.

The downside of the 'explain' approach is that the script then has to be
modified to put 'explain' in front of everything and then you have to go
through each statement and consider it.  Having a 'dry-run' transaction
type which then produces a report at the end feels like it'd be both
easier to assess the overall implications, and less error-prone as you
don't have to prefex every statement with 'explain'.  It might even be
possible to have the local "view" of post-alter statements be available
inside of this 'dry-run' option- that is, if you add a column in the
transaction then the column exists to the following commands, so it
doesn't just error out.  Having 'explain <whatever>' wouldn't give you
that and so you really wouldn't be able to have whole scripts run by
just pre-pending each command with 'explain'.

> >  3. Does it make sense to support the whole set of DDL commands from the
> >     get go (or ever) when most of them are only taking locks in their
> >     own pg_catalog entry anyway?
>
> I would think that introducing this incrementally makes sense.

Agreed.
Thanks,
    Stephen

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: DDL Damage Assessment
Следующее
От: Robert Haas
Дата:
Сообщение: Re: NEXT VALUE FOR