Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 6EBAA6502E4 for ; Thu, 24 Jul 2008 14:09:49 -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 77339-04 for ; Thu, 24 Jul 2008 14:09:45 -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 7FB076502AA for ; Thu, 24 Jul 2008 14:09:46 -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 m6OH9O6S008024; Thu, 24 Jul 2008 13:09:25 -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: <3073cc9b0807240917o1b100369lb97a57bf96f818b9@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> <20080712195237.GA22779@toroid.org> <24460.1215895820@sss.pgh.pa.us> <3073cc9b0807240917o1b100369lb97a57bf96f818b9@mail.gmail.com> Comments: In-reply-to "Jaime Casanova" message dated "Thu, 24 Jul 2008 11:17:07 -0500" Date: Thu, 24 Jul 2008 13:09:24 -0400 Message-ID: <8023.1216919364@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200807/1139 X-Sequence-Number: 121399 "Jaime Casanova" writes: >> Another issue is the interaction with the planned column-level GRANT >> feature. > Although that is a feature we want, is a WIP one... do we stop patches > because it can conflict with a project we don't know will be applied > soon? Well, considering that that one is implementing a feature required by SQL spec, your feature will lose any tug-of-war ;-). So yeah, you ought to consider how to make yours play nice when (not if) that happens. regards, tom lane