Re: How should row-security affects ON UPDATE RESTRICT / CASCADE ? - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: How should row-security affects ON UPDATE RESTRICT / CASCADE ?
Date
Msg-id 52707514.3000100@2ndquadrant.com
Whole thread Raw
In response to Re: How should row-security affects ON UPDATE RESTRICT / CASCADE ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: How should row-security affects ON UPDATE RESTRICT / CASCADE ?  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
List pgsql-hackers
On 10/30/2013 10:50 AM, Tom Lane wrote:
> Craig Ringer <craig@2ndquadrant.com> writes:
>> > I'd kind of like to see FK constraints affected by RLS for
>> > non-superusers, at least as an option.
> I think that's a complete nonstarter.  Aside from the fact that such a
> constraint will have no definable semantics, even the possibility that a
> constraint doesn't mean what it appears to mean will prevent us from
> making use of FK constraints for optimization --- something that's
> pretty high on the planner to-do list.

Good point. That's another good argument for FK constraints to disregard
RLS. In which case, is there actually any way to determine when an SPI
query is being invoked directly from an FK constraint? We'll need a way
to tell so RLS can skip adding the row-security check predicate.

Users who want FK-constraint-like behaviour can DIY with triggers,
getting whatever behaviour they need in the face of RLS.

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: How should row-security affects ON UPDATE RESTRICT / CASCADE ?
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: UNION ALL on partitioned tables won't use indices.