Re: [PATCH] Partial foreign key updates in referential integrity triggers
Matthias van de Meent <boekewurm+postgres@gmail.com>
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Paul Martinez <hellopfm@gmail.com>, Zhihong Yu <zyu@yugabyte.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-12-01T14:11:54Z
Lists: pgsql-hackers
On Wed, 1 Dec 2021 at 11:33, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > > On 23.11.21 05:44, Paul Martinez wrote: > > Updated patch attached. Thanks for taking a look so quickly! > > This patch looks pretty much okay to me. As I wrote in another message > in this thread, I'm having some doubts about the proper use case. So > I'm going to push this commit fest entry to the next one, so we can > continue that discussion. The use case of the original mail "foreign keys are guaranteed to not be cross-tenant" seems like a good enough use case to me? The alternative to the discriminator column approach to seperating tenant data even when following referential integrety checks would be maintaining a copy of the table for each tenant, but this won't work as well due to (amongst others) syscache bloat, prepared statements being significantly less effective, and DDL operations now growing linearly with the amount of tenants in the system. Kind regards, Matthias van de Meent
Commits
-
Allow specifying column list for foreign key ON DELETE SET actions
- d6f96ed94e73 15.0 landed
-
doc: Add referential actions to CREATE/ALTER TABLE synopsis
- db9f287711ac 15.0 landed