Re: WIP patch (v2) for updatable security barrier views - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP patch (v2) for updatable security barrier views
Date
Msg-id 27103.1397225017@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP patch (v2) for updatable security barrier views  (Stephen Frost <sfrost@snowman.net>)
Responses Re: WIP patch (v2) for updatable security barrier views
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Dean Rasheed (dean.a.rasheed@gmail.com) wrote:
>> Am I right in thinking that the "locking gotcha" only happens if you
>> create a security_barrier view conaining a "SELECT ... FOR UPDATE"? If
>> so, that seems like rather a niche case - not that that means we
>> shouldn't warn people about it.

> Hmm, the 'gotcha' I was referring to was the issue discussed upthread
> around rows getting locked to be updated which didn't pass all the quals
> (they passed the security_barrier view's, but not the user-supplied
> ones), which could happen during a normal 'update' against a
> security_barrier view, right?  I didn't think that would require the
> view definition to be 'FOR UPDATE'; if that's required then it would
> seem like we're actually doing what the user expects based on their view
> definition..

Yeah, the point of the "gotcha" is that a FOR UPDATE specified *outside* a
security-barrier view would act as though it had appeared *inside* the
view, since it effectively gets pushed down even though outer quals don't.
        regards, tom lane



pgsql-hackers by date:

Previous
From: "lkcl ."
Date:
Subject: Re: [feature] cached index to speed up specific queries on extremely large data sets
Next
From: Andres Freund
Date:
Subject: Signaling of waiting for a cleanup lock?