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

From Florian Pflug
Subject Re: augmenting MultiXacts to improve foreign keys
Date
Msg-id 8EF1FA5A-89D8-484D-BE00-2F60CF93555D@phlo.org
Whole thread Raw
In response to Re: augmenting MultiXacts to improve foreign keys  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Aug9, 2011, at 22:40 , Tom Lane wrote:
> 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.

True, but I still considered that to be a quite unfortunate limitation,
and one that I hope to one day remove. So I'd hate to see us adding more
stumbling blocks along that road. 

Even today, you can do user-space FK-like constraint if you restrict
yourself to either running all transaction in isolation level READ COMMITTED,
or all transactions in isolation level SERIALIZABLE (Though I in the later
case, you don't need locks anyway..)

best regards,
Florian Pflug



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: augmenting MultiXacts to improve foreign keys
Next
From: Florian Pflug
Date:
Subject: Re: augmenting MultiXacts to improve foreign keys