Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VdLHZ-0007Fg-Hg for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Nov 2013 14:37:33 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1VdLHZ-00029W-0r for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Nov 2013 14:37:33 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VdLHY-000294-4t for pgsql-hackers@postgresql.org; Mon, 04 Nov 2013 14:37:32 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1VdLHU-0004Ko-Tt for pgsql-hackers@postgresql.org; Mon, 04 Nov 2013 14:37:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id rA4EbJ1s011102; Mon, 4 Nov 2013 09:37:19 -0500 From: Tom Lane To: Craig Ringer cc: Robert Haas , Stephen Frost , Josh Berkus , Kohei KaiGai , "ktm@rice.edu" , Alexander Korotkov , Oleg Bartunov , Greg Smith , PgHacker Subject: Re: [v9.4] row level security In-reply-to: <52775604.9090306@2ndquadrant.com> References: <20130829142321.GA30496@aart.rice.edu> <521F7DFB.8060602@agliodbs.com> <5220D832.7090104@agliodbs.com> <20130830192729.GO2706@tamriel.snowman.net> <16798.1377891794@sss.pgh.pa.us> <1398.1378305956@sss.pgh.pa.us> <1543.1378306249@sss.pgh.pa.us> <2620.1378308159@sss.pgh.pa.us> <52775604.9090306@2ndquadrant.com> Comments: In-reply-to Craig Ringer message dated "Mon, 04 Nov 2013 16:08:36 +0800" Date: Mon, 04 Nov 2013 09:37:19 -0500 Message-ID: <11101.1383575839@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Craig Ringer writes: > On 09/04/2013 11:22 PM, Tom Lane wrote: >> AFAICT, to deal with update/delete the RLS patch needs to constrain order >> of qual application without the crutch of having a separate level of >> subquery; and it's that behavior that I have zero confidence in, either >> as to whether it works as submitted or as to our odds of not breaking it >> in the future. > Wouldn't CASE do that job, albeit in a somewhat ugly manner, and also > protect against malicious RLS functions? You mean wrap all the query quals in a CASE? Sure, if you didn't mind totally destroying any optimization possibilities. If you did that, every table scan would become a seqscan and every join a nestloop. 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