Re: augmenting MultiXacts to improve foreign keys - Mailing list pgsql-hackers

From Tom Lane
Subject Re: augmenting MultiXacts to improve foreign keys
Date
Msg-id 12383.1312922415@sss.pgh.pa.us
Whole thread Raw
In response to Re: augmenting MultiXacts to improve foreign keys  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: augmenting MultiXacts to improve foreign keys
Re: augmenting MultiXacts to improve foreign keys
Re: augmenting MultiXacts to improve foreign keys
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011:
>> Right now, FKs aren't really very special, they are mostly just
>> syntactic sugar (right?). This proposal would make FKs special internal
>> mechanisms, and I don't see the benefit in doing so.

> Well, you can get the same behavior by adding the constraint triggers
> manually.  But those triggers are written in C, so you could equally
> claim that they are "special internal" already.  The SPI interface has
> some special entry points to allow them to work correctly (for example
> passing a snapshot for the checks to run with).

Yeah, the crosscheck-snapshot logic already puts the lie to any idea
that the RI triggers are equivalent to anything available at the SQL
level.

ISTM you could pass down the "please do this with FOR KEY UPDATE not
just FOR SHARE" flag similarly to the way the crosscheck snapshot is
passed down, or maybe even just do it if you see a crosscheck snapshot
is present in the executor state (though that's a bit ugly).

Like Florian, I'm considerably more concerned about the aspect of
deciding which columns are "key columns" and whether they changed.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Ignore lost+found when checking if a directory is empty
Next
From: Alvaro Herrera
Date:
Subject: Re: augmenting MultiXacts to improve foreign keys