| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Thinking about EXPLAIN ALTER TABLE |
| Date: | 2018-12-10 16:52:50 |
| Message-ID: | 26597.1544460770@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2018-12-10 17:27:23 | Re: Thinking about EXPLAIN ALTER TABLE |
| Previous Message | Simon Riggs | 2018-12-10 16:45:49 | Re: Thinking about EXPLAIN ALTER TABLE |