Re: Improving RLS planning

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Improving RLS planning
Дата
Msg-id 22135.1478797921@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Improving RLS planning  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Improving RLS planning
Список pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Dean Rasheed (dean.a.rasheed@gmail.com) wrote:
>> On 8 November 2016 at 14:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> ... I'm still suspicious that the three places I found may
>>> represent bugs in the management of Query.hasRowSecurity.

>> I don't believe that there are any existing bugs here, but I think 1
>> or possibly 2 of the 3 places you changed should be kept on robustness
>> grounds (see below).

> Agreed.

OK.  I'll push a small patch that adds two of those and a comment as to
why it's not appropriate in the third case.  HEAD-only should be
sufficient since we don't think this is a live bug.

>> On a related note, I think it's worth establishing a terminology
>> convention for code and comments in this whole area.

> For my 2c, 'security' is a pretty overloaded term, unfortunately.

Yeah, I think we'd be best off to avoid the bare term "security".
It's probably too late to change the RTE field name "securityQuals",
but maybe we could uniformly call those "security barrier quals" in
the comments.  Then the basic terminology is that we have security
barrier views and row-level security both implemented on top of
security barrier quals, and we should be careful to use the right
one of those three terms in comments/documentation.

Or, if you are willing to put up with renaming the field, we could
call the RTE field "barrierQuals" and then they are just "barrier
quals" for documentation purposes.  But this would be a PITA for
back-patching, so I'm not sure it's worth it.
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: WAL consistency check facility
Следующее
От: David Steele
Дата:
Сообщение: Re: Fix checkpoint skip logic on idle systems by tracking LSN progress