Re: pgsql: Fix table rewrites that include a column without a default.

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-10-10 16:51:23 -0400, Tom Lane wrote:
>> Do you *really* need an event trigger to test this?

> No. I added it to avoid the tests getting "accidentally" optimized away,
> the next time somebody adds some ALTER TABLE optimizations. The fast
> default stuff had removed coverage from a test that'd have uncovered
> this bug. And an event trigger seemed to be the easiest way to achieve
> that.

> The only real alternative I can see to just removing the trigger is
> embedding a check in the trigger that will cause it to only work in the
> current session. Something like SET regress.log_table_rewrites, and a
> IF current_setting('regress.log_table_rewrites')::bool in the function.

If you just want to verify that a rewrite happened or didn't happen,
seems like you could check whether the table's relfilenode changed.

regression=# select relfilenode as oldfilenode from pg_class where relname = 'rewrite_test'
regression-# \gset
regression=# select relfilenode != :oldfilenode as changed from pg_class where relname = 'rewrite_test';
changed
---------
f
(1 row)
regression=# alter table rewrite_test alter column notempty3_norewrite type bigint;
ALTER TABLE
regression=# select relfilenode != :oldfilenode as changed from pg_class where relname = 'rewrite_test';
changed
---------
t
(1 row)

I really really don't want an event trigger running in everything that
runs in parallel with alter_table. That's a debugging nightmare of
monster proportions.

regards, tom lane