Date: Wed, 16 Oct 2019 02:48:36 -0700
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Fix table rewrites that include a column without a
 default.
Message-ID: <20191016094836.nh3akqg2j72wncnz@alap3.anarazel.de>
References: <E1iIQrV-0005gk-1D@gemulon.postgresql.org>
 <3328.1570740683@sss.pgh.pa.us>
 <20191010205903.tj73q3qcyfft3izz@alap3.anarazel.de>
 <4541.1570742168@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4541.1570742168@sss.pgh.pa.us>
Precedence: bulk

Hi,

On 2019-10-10 17:16:08 -0400, Tom Lane wrote:
> 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)

This felt verbose to me over a number of to-be-tested statements, so I
instead replaced it with a plpgsql function that EXECUTEs the DDL and
returns whether a rewrite happened. I'll assume/hope that that fixes the
occasional bf failures.

Greetings,

Andres Freund