Re: Infinite recursion in row-security based on updatable s.b. views

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Gregory Smith <gregsmithpgsql(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Infinite recursion in row-security based on updatable s.b. views
Date: 2014-01-28 08:39:50
Message-ID: 52E76CD6.1010704@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
RangeTblEntry instead of an rt_index.

That'd also be much more efficient with large rtables if we can arrange
a scan through the rtable when looking for security quals.

Like other places that operate on the rangetable while it's being
modified, we can walk the rangetable list up until the final entry that
existed when we started walking. This approach saves the series of
rt_fetch calls, which are something like O(n log n) for n relations.

It's safe because the operation will only append rangetable entries.

(I can't help wonder how much we'd gain by making the rtable an array
that gets doubled in size and copied whenever it overflows, rather than
a linked list, given all the walking of it that gets done, and how dead
entries to get flagged as dead rather than actually removed.)

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.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-01-28 08:45:00 Re: Storing pg_stat_statements query texts externally, pg_stat_statements in core
Previous Message Yugo Nagata 2014-01-28 08:38:11 Re: Fwd: Proposal: variant of regclass