Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 7D526635371 for ; Sun, 16 Aug 2009 10:21:49 -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 78964-09 for ; Sun, 16 Aug 2009 13:21:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from frubble.xen.chris-lamb.co.uk (frubble.xen.chris-lamb.co.uk [89.16.166.12]) by mail.postgresql.org (Postfix) with ESMTP id 2BA0A634E41 for ; Sun, 16 Aug 2009 10:21:41 -0300 (ADT) Received: from sam by frubble.xen.chris-lamb.co.uk with local (Exim 4.63) (envelope-from ) id 1Mcfg2-0005uh-N8 for pgsql-hackers@postgresql.org; Sun, 16 Aug 2009 14:21:38 +0100 Date: Sun, 16 Aug 2009 14:21:38 +0100 From: Sam Mason To: pgsql-hackers@postgresql.org Subject: Re: GRANT ON ALL IN schema Message-ID: <20090816132138.GY5407@samason.me.uk> References: <2CCE9C1D-919D-45D5-BFC2-C7723C45064E@hi-media.com> <162867790908150434j7aef36ecm202e81c4bb4740fa@mail.gmail.com> <4A86B5D5.6060807@dunslane.net> <4A871F46.1040002@agliodbs.com> <5D5ECAE0-F2B0-479B-9594-50AAF18F10ED@hi-media.com> <20090815223102.GS5407@samason.me.uk> <1250378139.18992.6.camel@vanquo.pezone.net> <603c8f070908152051mbd1d706hb0e29f5cfaf2f151@mail.gmail.com> <4A87854B.3070707@dunslane.net> <1250427428.26280.2.camel@vanquo.pezone.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1250427428.26280.2.camel@vanquo.pezone.net> User-Agent: Mutt/1.5.13 (2006-08-11) 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/1222 X-Sequence-Number: 143865 On Sun, Aug 16, 2009 at 03:57:08PM +0300, Peter Eisentraut wrote: > On 2009-08-16 at 00:04 -0400, Andrew Dunstan wrote: > > SQL is not Lisp. Simple is good. I didn't think Peter was really very > > serious. > > Well, I don't know if we really need to call it "lambda", but I fully > expect to be able to use these "ad hoc functions" as part of other > expressions. So making DO or whatever a top-level command that does not > integrate with anything else would not really satisfy me. Wow, I didn't think you were serious either! One thing that would make my life easier would be easier one-off custom aggregations, this would seem to be a nice stepping stone towards that. For instance the following "agg" function would have similar semantics to "fold", as found in functional languages. SELECT agg(LAMBDA (text,text) $$ SELECT $1||coalesce($2,''); $$, '', s) FROM (VALUES ('aa'), ('bb')) x(s); I'd expect to get 'aabb' back if I've done something wrong/it's not obvious. I.e. the first parameter is like the SFUNC in CREATE AGGREGATE, the second parameter ('') is the INITCOND, and the third param (s) is what you want to aggregate. You've now got two type variables in play and hence you'd want some better support of parametric polymorphism than PG currently makes easy. The current AGGREGATE infrastructure seems to get away with it by bundling this type knowledge into the aggregate itself. Also, why isn't SQL the default language--plpgsql still needs to be explicitly added doesn't it? -- Sam http://samason.me.uk/