Re: Odd behavior of updatable security barrier views on foreign tables

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Odd behavior of updatable security barrier views on foreign tables
Дата
Msg-id 20150217224451.GE6717@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Odd behavior of updatable security barrier views on foreign tables  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Ответы Re: Odd behavior of updatable security barrier views on foreign tables  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список pgsql-hackers
Etsuro,

* Etsuro Fujita (fujita.etsuro@lab.ntt.co.jp) wrote:
> On 2015/02/11 4:06, Stephen Frost wrote:
> >I had been trying to work out an FDW-specific way to address this, but I
> >think Dean's right that this should be addressed in
> >expand_security_qual(), which means it'll apply to all cases and not
> >just these FDW calls.  I don't think that's actually an issue though and
> >it'll match up to how SELECT FOR UPDATE is handled today.
>
> Sorry, my explanation was not accurate, but I also agree with Dean's
> idea.  In the above, I just wanted to make it clear that such a lock
> request done by expand_security_qual() should be limited to the case
> where the relation that is a former result relation is a foreign
> table.

Attached is a patch which should address this.  Would love your (or
anyone else's) feedback on it.  It appears to address the issue which
you raised and the regression test changes are all in-line with
inserting a LockRows into the subquery, as anticipated.

    Thanks!

        Stephen

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Oskari Saarenmaa
Дата:
Сообщение: Re: Configurable location for extension .control files
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: sloppy back-patching of column-privilege leak