X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id E58E29DC94A for ; Mon, 13 Mar 2006 11:12:53 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 64938-07 for ; Mon, 13 Mar 2006 11:12:52 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from gozer.look.ca (epsilon1.look.ca [207.136.80.10]) by postgresql.org (Postfix) with ESMTP id 150719DC851 for ; Mon, 13 Mar 2006 11:12:46 -0400 (AST) Received: from 216-154-16-182.dsl.look.ca ([216.154.16.182]) by gozer.look.ca with esmtp (Exim 4.20) id 1FIoj4-0007FG-8W; Mon, 13 Mar 2006 15:12:50 +0000 From: Rod Taylor To: Alvaro Herrera Cc: "Eugene E." , pgsql-sql@postgresql.org In-Reply-To: <20060313144617.GG8274@surnet.cl> References: <441540AA.3090202@bankir.ru> <1142260392.857.49.camel@home> <20060313144617.GG8274@surnet.cl> Date: Mon, 13 Mar 2006 10:10:51 -0500 Message-Id: <1142262651.857.77.camel@home> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port X-SA-Exim-Mail-From: pg@rbt.ca Subject: Re: Permission to Select Content-Type: text/plain Content-Transfer-Encoding: 7bit X-SA-Exim-Version: 3.1 (built Tue Feb 24 05:09:27 GMT 2004) X-SA-Exim-Scanned: Yes X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.06 required=5 tests=[AWL=0.060] X-Spam-Score: 0.06 X-Spam-Level: X-Archive-Number: 200603/191 X-Sequence-Number: 24537 On Mon, 2006-03-13 at 10:46 -0400, Alvaro Herrera wrote: > Rod Taylor wrote: > > > By allowing the user a where clause you grant them select privileges. > > You will find that delete works the same way. > > > > This is one of those times when per column permissions are useful. You > > could grant them select access on the "name" column but not the "salary" > > column. > > If I understand clearly, the patch he posted modified things so that if > the user issued an UPDATE command, the SELECT permission was required as > well. Thus a user with UPDATE privileges but no SELECT was not allowed > to execute the UPDATE command. Okay, I got it backward. The exclamation mark behind the first point made me think it was an issue. What information can be retrieved from a structure by being able to update all rows? You possibly find the range of values (max/min via integer overflow) but still would not know which tuple is associated with which value. I don't have a use-case for update but the delete / insert combination is quite handy for doing data resets from a host which should not be able to retrieve the interim states.