From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kohei KaiGai <kaigai@kaigai.gr.jp>
cc: Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>,
 Josh Berkus <josh@agliodbs.com>, "ktm@rice.edu" <ktm@rice.edu>,
 Alexander Korotkov <aekorotkov@gmail.com>,
 Oleg Bartunov <obartunov@gmail.com>, Greg Smith <greg@2ndquadrant.com>,
 PgHacker <pgsql-hackers@postgresql.org>
Subject: Re: [v9.4] row level security
In-reply-to: 
 <CADyhKSUkQnG5POG7abhLTA_FJQ6QWU6Js71xRHdb0niDcjBg2A@mail.gmail.com>
References: 
 <CADyhKSWkHrPqbRsFK0LjPMOOTsbKGWOuN75GqYJrxCDO3CKWtA@mail.gmail.com>
 <CAPpHfdsgMrBnzu9um48O6kwY=_pRFuRrBrHqnA03fCAo8x3-Gg@mail.gmail.com>
 <CADyhKSUpcYKNm3rQRwCFqkTZfO3_ZrqYKjAqDxKeA6WeLezSbw@mail.gmail.com>
 <20130829142321.GA30496@aart.rice.edu>
 <CADyhKSUD7qdQeTndZ6mDpp05V6MnRBzQO1FmYBq1+Zp37oyRrg@mail.gmail.com>
 <WM!685df689dd4d8f8c5349d5ef7b8e285db1e99ea32d22ab5d35f3981c29eac19dbd725c9b5e0227def9d782de274d1354!@asav-3.01.com>
 <521F7DFB.8060602@agliodbs.com>
 <CADyhKSW_o2nVWFytdTY84DUXZSuZkD_EtY2d8wAjR18UruOXYQ@mail.gmail.com>
 <WM!fb94ecb91cd381e69d8e4773d3810f48e4e0ef000525cc806c4ee509f215ce1a39c8c2a1c3ffde72ba2ddb1a07ebcdc9!@asav-2.01.com>
 <5220D832.7090104@agliodbs.com> <20130830192729.GO2706@tamriel.snowman.net>
 <16798.1377891794@sss.pgh.pa.us>
 <CA+TgmoZYv_me1iB6iDRA_oO-o9xkxXYqr-0UtwK5itpZbDsqYA@mail.gmail.com>
 <1398.1378305956@sss.pgh.pa.us>
 <CA+TgmoYTf+4RUOW8stVz1RE+3TD+QR5TNKzYuFDCehSkieL5OQ@mail.gmail.com>
 <1543.1378306249@sss.pgh.pa.us> <CADyhKSUkQnG5PO!
 G7abhLTA_FJQ6QWU6Js71xRHdb0niDcjBg2A@mail.gmail.com>
Comments: In-reply-to Kohei KaiGai <kaigai@kaigai.gr.jp>
 message dated "Wed, 04 Sep 2013 17:28:59 +0200"
Date: Wed, 04 Sep 2013 11:58:19 -0400
Message-ID: <3942.1378310299@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Kohei KaiGai <kaigai@kaigai.gr.jp> writes:
> 2013/9/4 Tom Lane <tgl@sss.pgh.pa.us>:
>> And for insert/update/delete, we do what exactly?

> Regarding to update/delete, this patch also enhanced to allow update or
> delete mechanism allows to take a sub-query on top of the table scan plan.

> So, its explain output shows as follows:

> postgres=> EXPLAIN (costs off) UPDATE customer SET email = 'alice@example.com';
>                     QUERY PLAN
> --------------------------------------------------
>  Update on customer
>    ->  Subquery Scan on customer
>          ->  Seq Scan on customer customer_1
>                Filter: ("current_user"() = uname)

> You can see this update has Subquery plan instead of regular relation scan.

Really?  That wasn't apparent from reading the patch.  (Have I mentioned
it's desperately underdocumented?  Aside from needing a lot more in-code
comments than it's got, it would benefit from having an overview section
added to optimizer/README explaining stuff at the level of this
discussion.)

I'm a bit surprised that setrefs.c doesn't eliminate the Subquery Scan as
being a no-op, given that no quals end up getting applied at that level.
You might look into why not, since if that plan node were eliminated at
the end, it'd fix any efficiency complaints about this approach.

			regards, tom lane


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