Re: [PATCH] Partial foreign key updates in referential integrity triggers - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: [PATCH] Partial foreign key updates in referential integrity triggers
Date
Msg-id CAEze2Wj=4g1RbMA_w8X_k9NRJ01anZsg3VqjAhz=srqOUpAcfg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Partial foreign key updates in referential integrity triggers  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: [PATCH] Partial foreign key updates in referential integrity triggers  (Paul Martinez <hellopfm@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: stat() vs ERROR_DELETE_PENDING, round N + 1
Next
From: Peter Eisentraut
Date:
Subject: Re: Reserve prefixes for loaded libraries proposal