Message-ID: <52E76CD6.1010704@2ndquadrant.com>
Date: Tue, 28 Jan 2014 16:39:50 +0800
From: Craig Ringer <craig@2ndquadrant.com>
Organization: 2nd Quadrant
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Dean Rasheed <dean.a.rasheed@gmail.com>
CC: Gregory Smith <gregsmithpgsql@gmail.com>, Greg Stark <stark@mit.edu>,
 Kohei KaiGai <kaigai@kaigai.gr.jp>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Infinite recursion in row-security based on updatable s.b. views
References: 
 <CADyhKSWkHrPqbRsFK0LjPMOOTsbKGWOuN75GqYJrxCDO3CKWtA@mail.gmail.com>
	<1398.1378305956@sss.pgh.pa.us>
	<CA+TgmoYTf+4RUOW8stVz1RE+3TD+QR5TNKzYuFDCehSkieL5OQ@mail.gmail.com>
	<1543.1378306249@sss.pgh.pa.us>	<2620.1378308159@sss.pgh.pa.us>
	<52775604.9090306@2ndquadrant.com>	<11101.1383575839@sss.pgh.pa.us>
	<CA+TgmoZS46fGTHCMo1FpNiBYDU7Wrx7R8PL+48Xc7UcVCsuaUA@mail.gmail.com>
	<52784DF9.9040205@2ndquadrant.com>
	<CA+TgmobvM9t8y6+BoG0DXMVA5jcNc9V6fzNt2tNSaVqsRmGpHA@mail.gmail.com>
	<5279E3CA.7050400@2ndquadrant.com>
	<CAM-w4HOJaWt2naKakW67KRZE9mBcEF-BQ3UA=7SHKcFv3=FmVQ@mail.gmail.com>
	<527C478D.4070901@2ndquadrant.com>	<52ABCF6C.4010409@gmail.com>
	<52ABE150.6050201@2ndquadrant.com>	<52D98436.2030508@gmail.com>
	<52DC82E2.5010801@2ndquadrant.com>	<52DCBEF1.3010004@2ndquadrant.com>
	<52E1CC04.8040907@2ndquadrant.com>	<52E1DAD8.30909@2ndquadrant.com>
	<52E22C8E.2020702@2ndquadrant.com>
 <CAEZATCVJPnUrLjsS626Pp+r_bdq-3ofRHWmV0fKx1OgpyLt5ww@mail.gmail.com>
In-Reply-To: 
 <CAEZATCVJPnUrLjsS626Pp+r_bdq-3ofRHWmV0fKx1OgpyLt5ww@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers