Re: foreign key locks, 2nd attempt

On Sat, Nov 19, 2011 at 10:36 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
>> On Thu, Nov 3, 2011 at 6:12 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>>> So Noah Misch proposed using the FOR KEY SHARE syntax, and that's what I
>>> have implemented here.  (There was some discussion that instead of
>>> inventing new SQL syntax we could pass the necessary lock mode
>>> internally in the ri_triggers code.  That can still be done of course,
>>> though I haven't done so in the current version of the patch.)
>
>> FKs are a good short hand, but they aren't the only constraint people
>> implement. It can often be necessary to write triggers to enforce
>> complex constraints. So user triggers need access to the same
>> facilities that ri triggers uses. Please keep the syntax.
>
> It's already the case that RI triggers require access to special
> executor features that are not accessible at the SQL level.  I don't
> think the above argument is a compelling reason for exposing more
> such features at the SQL level.  All we need is that C-coded functions
> can get at them somehow.

I kinda agree with Simon. In general, if we don't need to expose
something at the SQL level, then sure, let's not. But it seems weird
to me to say, well, we have four lock modes internally, and you can
get to three of them via SQL. To me, that sort of inconsistency feels
like a wart.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company