Re: WIP patch (v2) for updatable security barrier views

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WIP patch (v2) for updatable security barrier views
Дата
Msg-id 27103.1397225017@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WIP patch (v2) for updatable security barrier views  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: WIP patch (v2) for updatable security barrier views  (Stephen Frost <sfrost@snowman.net>)
Список 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 по дате отправления:

Предыдущее
От: "lkcl ."
Дата:
Сообщение: Re: [feature] cached index to speed up specific queries on extremely large data sets
Следующее
От: Andres Freund
Дата:
Сообщение: Signaling of waiting for a cleanup lock?