Re: Thinking about EXPLAIN ALTER TABLE

On Mon, 10 Dec 2018 at 16:52, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > On Mon, 10 Dec 2018 at 16:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> We were just busy shooting down a different suggestion of
> >> behavior-changing GUCs. A GUC that turns all ALTERs into no-ops
> >> sure seems like a foot-gun to me.
>
> > How would you test a script? Manually edit each one with the new option?
> > Manual editing is more of a foot gun.
>
> I don't see how EXPLAIN ALTER TABLE would meaningfully be something
> you use in a script. If you have a script with many steps including
> ALTER TABLEs, it's likely that each ALTER depends on the effects of
> prior steps, and it's even more likely that the steps after an ALTER
> depend on it having executed.
>

Agreed, but that's why I suggested an alternative.

Remembering, the best approach is one we have already taken.... but maybe
we have forgotten.

An event trigger with a table_rewrite event, allows you to scan a whole
script for objectionable activity on a test server before you put it into
production.

Perhaps we just need a few extra events.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services