Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 14918650B3E for ; Sat, 12 Jul 2008 17:07:08 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 44725-06 for ; Sat, 12 Jul 2008 17:06:58 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 8EB00650B1B for ; Sat, 12 Jul 2008 17:06:59 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id m6CK6pLl023913; Sat, 12 Jul 2008 16:06:51 -0400 (EDT) To: "Jaime Casanova" cc: "Abhijit Menon-Sen" , "Alvaro Herrera" , "Jaime Casanova" , pgsql-hackers@postgresql.org Subject: Re: Extending grant insert on tables to sequences In-reply-to: <3073cc9b0807121232m6b8e6ae0ycaa78d6b8595d39d@mail.gmail.com> References: <20080708133244.GB4095@alvh.no-ip.org> <20080709185837.GA27406@toroid.org> <20080709191125.GK3946@alvh.no-ip.org> <20080710031140.GA427@toroid.org> <3073cc9b0807110957w71869487p17fb58cb98abc520@mail.gmail.com> <20080712113041.GA25112@toroid.org> <3073cc9b0807121232m6b8e6ae0ycaa78d6b8595d39d@mail.gmail.com> Comments: In-reply-to "Jaime Casanova" message dated "Sat, 12 Jul 2008 14:32:03 -0500" Date: Sat, 12 Jul 2008 16:06:51 -0400 Message-ID: <23912.1215893211@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200807/624 X-Sequence-Number: 120884 "Jaime Casanova" writes: > + if (istmt.all_privs) > + istmt_seq.all_privs = true; > + else > + { > + if (istmt.privileges & ACL_INSERT) > + istmt_seq.privileges |= ACL_USAGE; > + if (istmt.privileges & ACL_UPDATE) > + istmt_seq.privileges |= ACL_UPDATE; > + if (istmt.privileges & ACL_SELECT) > + istmt_seq.privileges |= ACL_SELECT; > + } This definition of the derived rights seems pretty arbitrary and unprincipled. If you can't explain it precisely in a few words in the documentation (and I notice you didn't even attempt to explain it at all), then you probably need to think harder. In particular, I don't see why having UPDATE on the parent table should grant the right to use setval() on the sequence. If you had INSERT and DELETE as well, implying the right to make arbitrary changes in the parent table, then maybe setval() would be sensible to allow --- but this code can't really tell that, since it doesn't have a global view of the privileges previously granted. What I think makes sense is just to have parent INSERT privilege lead to USAGE on the sequence (thus granting nextval/currval rights, which are what you'd typically need in association with trying to do inserts). I don't see any need to automatically grant more than that. Selects and updates on the parent table don't need to touch the sequence, so why are those privileges granting anything? regards, tom lane