Excerpts from Jeff Davis's message of mar ago 09 14:41:14 -0400 2011:
> On Tue, 2011-08-09 at 13:01 -0400, Alvaro Herrera wrote:
> > Note that the KEY UPDATE lock would be an internal option, not exposed
> > to SQL. I think we already have enough extensions in this area. We are
> > forced to expose KEY SHARE because RI triggers get to it via SPI, but I
> > would be happy to avoid doing it if I knew how.
>
> 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).
In any case, this is certainly not something I'm really interested in
doing. I don't have a problem with simply adding the new syntax to SQL
and documenting it appropriately ("this is only for internal RI use").
> [ I didn't read through the previous threads yet, so perhaps this was
> already discussed. ]
Nope.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support