Re: Improving RLS planning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Improving RLS planning
Date
Msg-id 22135.1478797921@sss.pgh.pa.us
Whole thread Raw
In response to Re: Improving RLS planning  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Improving RLS planning  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: WAL consistency check facility
Next
From: David Steele
Date:
Subject: Re: Fix checkpoint skip logic on idle systems by tracking LSN progress