Re: Thinking about EXPLAIN ALTER TABLE

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Thinking about EXPLAIN ALTER TABLE
Дата
Msg-id CANP8+jJHo4tLsHsMcwPF+a9N0HSXYz=KZLCNdh6t=CiQPoc=dA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Thinking about EXPLAIN ALTER TABLE  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Thinking about EXPLAIN ALTER TABLE  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Thinking about EXPLAIN ALTER TABLE
Следующее
От: Paul Ramsey
Дата:
Сообщение: Re: Dead code in toast_fetch_datum_slice?