Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 6A6B3632227 for ; Wed, 5 Aug 2009 14:18:41 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 11859-01 for ; Wed, 5 Aug 2009 17:18:31 +0000 (UTC) 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 mail.postgresql.org (Postfix) with ESMTP id A3067632840 for ; Wed, 5 Aug 2009 14:18:30 -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 n75HIRGU021543; Wed, 5 Aug 2009 13:18:27 -0400 (EDT) To: Petr Jelinek cc: PostgreSQL-development Subject: Re: GRANT ON ALL IN schema In-reply-to: <4A607997.3030305@pjmodos.net> References: <4A37BF63.50008@pjmodos.net> <4A37E122.8070303@pjmodos.net> <4A38A956.8080600@pjmodos.net> <4A4DE104.8090605@pjmodos.net> <4A6059B4.5010004@pjmodos.net> <4A607997.3030305@pjmodos.net> Comments: In-reply-to Petr Jelinek message dated "Fri, 17 Jul 2009 15:16:07 +0200" Date: Wed, 05 Aug 2009 13:18:27 -0400 Message-ID: <21542.1249492707@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.599 tagged_above=-10 required=5 tests=BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 200908/336 X-Sequence-Number: 142979 Petr Jelinek writes: > One more typo fix in docs I took a quick look at this version of the patch. Other than the already-mentioned question of whether we really want to create a distinction between tables and views in GRANT, there's not that much there to criticize. I do have a feeling that the implementation is a bit too narrowly focused on the "stuff IN SCHEMA foo" case; if we were ever to add other filtering options it seems like we'd have to rip all this code out and start over. But I don't have any immediate ideas on what it should look like instead. You mentioned that you weren't having any luck making "SCHEMA" optional in the syntax. I'm inclined to think it should be required rather than leave it out entirely. Leaving it out seems like it risks foreclosing future expansion --- are we sure there will never be another selection option that we'd want to start with IN? Putting the search functions (getNamespacesObjectsOids and getRelationsInNamespace) into aclchk.c doesn't seem quite right. I'd have been inclined to put them in namespace.c instead, I think. On the other hand objectNamesToOids hasn't been abstracted at all, so maybe this is fine as-is. Other than that I don't have much to say. I wonder though if this approach isn't sort of a dead-end, and we should instead look at making it easier to build sql or plpgsql functions for doing bulk grants with arbitrary selection conditions. regards, tom lane