From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: foreign key locks, 2nd attempt |
Date: | 2011-11-21 20:26:55 |
Message-ID: | m2aa7pfchc.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Nov 19, 2011 at 10:36 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
+1
I know I've already rolled constraint triggers into production, being
able to use FOR KEY SHARE locks would be good.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-11-21 20:36:59 | Re: Refactoring on DROP/ALTER SET SCHEMA/ALTER RENAME TO statement |
Previous Message | Bruce Momjian | 2011-11-21 20:08:33 | Re: pgsql: Do missed autoheader run for previous commit. |