Re: BUG #18156: Self-referential foreign key in partitioned table not enforced on deletes

I've since discovered that this is a regression in PG 15.x, with 14.x the
delete command correctly fails with an FK violation error.

Is there anything I can do to help investigating a root cause / fix for
this issue?

On Fri, Oct 13, 2023 at 10:27 AM PG Bug reporting form <
noreply(at)postgresql(dot)org> wrote:

> The following bug has been logged on the website:
>
> Bug reference: 18156
> Logged by: Matthew Gabeler-Lee
> Email address: fastcat(at)gmail(dot)com
> PostgreSQL version: 16.0
> Operating system: Linux
> Description:
>
> When a partitioned table has a self-referential foreign key, I'm finding
> that the key is not enforced during deletes from the table.
>
> A simple repro script:
>
> create table x (
> p int4 not null,
> i int4 not null,
> f int4 null,
> primary key (p, i),
> foreign key (p, f) references x (p, i)
> )
> partition by list (p);
> create table x1 partition of x for values in (0);
>
> insert into x values (0,1,null), (0,2,1);
> delete from x where (p,i) = (0,1);
> select * from x;
>
> The final select shows the one row with the clearly violated foreign key
> values:
> p | i | f
> ---+---+---
> 0 | 2 | 1
> (1 row)
>
> I've reproduced this with 15.4 and 16.0 using the official docker images,
> specifically `postgres/15-alpine` and `postgres/16-alpine`. I haven't
> tested
> older versions as my application requires features new to 15.x. I've tried
> with both list and hash partitioning, and it reproduces with both. I can
> only reproduce it with self-referential foreign keys and only with
> partitioned tables.
>
> I discovered this with a slightly more complex situation involving an `on
> delete set null` clause in the FK, but as seen above that is not required
> to
> reproduce the issue.
>
>