Обсуждение: BUG #16153: foreign key update should probably move dependent rows in the case of tuple rerouting

The following bug has been logged on the website:

Bug reference:      16153
Logged by:          Arne Roland
Email address:      a.roland@index.de
PostgreSQL version: 12.1
Operating system:   debian
Description:

--instead of simply deleting them silently
create table a (id serial, primary key (id)) partition by range (id);
create table b (id serial,  primary key (id)) partition by range (id);
alter table b add constraint a_fk foreign key (id) references a (id) on
delete cascade;
create table a1 partition of a for values from (1) to (2);
create table a2 partition of a for values from (2) to (3);
create table b1 partition of b for values from (1) to (2);
create table b2 partition of b for values from (2) to (3);

insert into a (id) values (1);
insert into b (id) values (1);

update a set id=2;

select * from b;

Regards
Arne

On 2019-Dec-05, PG Bug reporting form wrote:

> foreign key update should probably move dependent rows in the case of
> tuple rerouting
> instead of simply deleting them silently

Hmm.

> create table a (id serial, primary key (id)) partition by range (id);
> create table b (id serial,  primary key (id)) partition by range (id);
> alter table b add constraint a_fk foreign key (id) references a (id) on
> delete cascade;
> create table a1 partition of a for values from (1) to (2);
> create table a2 partition of a for values from (2) to (3);
> create table b1 partition of b for values from (1) to (2);
> create table b2 partition of b for values from (2) to (3);
> 
> insert into a (id) values (1);
> insert into b (id) values (1);
> 
> update a set id=2;
> 
> select * from b;

This seems to be a side-effect of how tuple updates work across
partitions.  My bet is that it's seen as just a deletion, which deletes
the referencing tuple because of the ON DELETE CASCADE; then the other
row is inserted and nothing else needs to happen.

You don't have ON UPDATE CASCADE in your example, so my expectation
would be that this should raise an error, per NO ACTION.  But if you
were to add ON UPDATE CASCADE, then yeah the referencing row should be
moved too somehow.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services