Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 4C0901927160 for ; Tue, 26 Jun 2012 18:00:16 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Sjcrv-00011m-00 for pgsql-hackers@postgresql.org; Tue, 26 Jun 2012 21:00:15 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q5QKxtvw013018; Tue, 26 Jun 2012 16:59:55 -0400 (EDT) From: Tom Lane To: Kohei KaiGai cc: Robert Haas , Florian Pflug , PgHacker Subject: Re: [v9.3] Row-Level Security In-reply-to: References: Comments: In-reply-to Kohei KaiGai message dated "Tue, 26 Jun 2012 22:36:15 +0200" Date: Tue, 26 Jun 2012 16:59:55 -0400 Message-ID: <13017.1340744395@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201206/1564 X-Sequence-Number: 210404 Kohei KaiGai writes: > 2012/6/26 Robert Haas : >> I think you're missing the point.  Everyone who has commented on this >> issue is in favor of having some check that causes the RLS predicate >> *not to get added in the first place*. > Here is a simple idea to avoid the second problematic scenario; that > assign 0 as cost of has_superuser_privilege(). I am not sure which part of "this isn't safe" isn't getting through to you. Aside from the scenarios Robert mentioned, consider the possibility that f_malicious() is marked immutable, so that the planner is likely to call it (to replace the call with its value) before it will ever think about whether has_superuser_privilege should be called first. Please just do what everybody is asking for, and create a bypass that does not require fragile, easily-broken-by-future-changes assumptions about what the planner will do with a WHERE clause. regards, tom lane