On 01/28/2014 02:11 PM, Craig Ringer wrote:
My first thought is to add a boolean flag to RangeTblEntry (similar to
the inh flag) to say whether RLS expansion is requested for that
RTE. Then set it to false on each RTE as you add new RLS quals to it's
securityQuals.
That's what I was
On 01/24/2014 07:16 PM, Dean Rasheed wrote:
think recursively calling the rewriter
to expand view references in the new RLS qual, and
expand_security_qual() to expand any additional RLS quals in the
securityQuals list
With this, it'd be helpful if expand_security_qual(...) took a
On 01/28/2014 04:39 PM, Craig Ringer wrote:
I'm looking for where I found the code that already does this so I can
point and say I'm not crazy, we already do it here. Will follow up
with a patch.
I spoke to soon. The code I'm talking about is
expand_inherited_tables(...) and it still uses
On 01/24/2014 07:16 PM, Dean Rasheed wrote:
My first thought is to add a boolean flag to RangeTblEntry (similar to
the inh flag) to say whether RLS expansion is requested for that
RTE. Then set it to false on each RTE as you add new RLS quals to it's
securityQuals.
That's what I was getting
Hi all
I've hit an interesting wrinkle and am interested in opinions. By
integrating updatable security barrier view support with row-security,
it has become a lot harder to detect and prevent infinite recursion
(including mutual recursion) in row-security policy expansion.
The code is attached,
On 24 January 2014 09:04, Craig Ringer cr...@2ndquadrant.com wrote:
Hi all
I've hit an interesting wrinkle and am interested in opinions. By
integrating updatable security barrier view support with row-security,
it has become a lot harder to detect and prevent infinite recursion
(including
