Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 1D86C6341B3 for ; Wed, 5 Aug 2009 17:55:22 -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 40403-09 for ; Wed, 5 Aug 2009 20:55:11 +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 963CA633AF9 for ; Wed, 5 Aug 2009 17:55:11 -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 n75Kt6Fj029602; Wed, 5 Aug 2009 16:55:06 -0400 (EDT) To: Josh Berkus cc: Robert Haas , Petr Jelinek , PostgreSQL-development Subject: Re: GRANT ON ALL IN schema In-reply-to: <4A79ECDF.4020700@agliodbs.com> 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> <21542.1249492707@sss.pgh.pa.us> <4A79D60D.1090900@agliodbs.com> <603c8f070908051221u676e9d68ya42f5099aafb2e8e@mail.gmail.com> <28123.1249501226@sss.pgh.pa.us> <4A79ECDF.4020700@agliodbs.com> Comments: In-reply-to Josh Berkus message dated "Wed, 05 Aug 2009 13:34:39 -0700" Date: Wed, 05 Aug 2009 16:55:06 -0400 Message-ID: <29601.1249505706@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/364 X-Sequence-Number: 143007 Josh Berkus writes: >> Josh's position that "this should be standard SQL" is nonsense, or >> at least he ought to be making that argument to the standards committee >> not us. > Huh? When did I say that? Sorry, I think I got one of your messages confused with one of Robert's. Anyway, > *Built-in* functions are just as good as extra syntax, as far as I'm > concerned. > Functions which require installing plpgsql, reading the docs, creating a > function, pasting it in, and saving it are NOT as good; they are > unlikely to ever be used, except by the people who didn't really need > them in the first place. Agreed, whatever we want to provide here should be available in a vanilla installation. This might argue for providing a C-code implementation instead of plpgsql, since I'm not sure we are yet ready to have plpgsql force-installed. But we can certainly design and prototype in plpgsql. regards, tom lane