Re: Thinking about EXPLAIN ALTER TABLE - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Thinking about EXPLAIN ALTER TABLE
Date
Msg-id CANP8+jJHo4tLsHsMcwPF+a9N0HSXYz=KZLCNdh6t=CiQPoc=dA@mail.gmail.com
Whole thread Raw
In response to Re: Thinking about EXPLAIN ALTER TABLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Thinking about EXPLAIN ALTER TABLE
List pgsql-hackers
On Mon, 10 Dec 2018 at 16:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Simon Riggs <simon@2ndquadrant.com> writes:
> On Mon, 10 Dec 2018 at 16:32, Tom Lane <tgl@sss.pgh.pa.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/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Thinking about EXPLAIN ALTER TABLE
Next
From: Paul Ramsey
Date:
Subject: Re: Dead code in toast_fetch_datum_slice?