Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 6218D635B9B for ; Fri, 21 Aug 2009 19:11:28 -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 32713-09 for ; Fri, 21 Aug 2009 22:11:18 +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 3A159635B59 for ; Fri, 21 Aug 2009 19:11:17 -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 n7LMBEcE011482; Fri, 21 Aug 2009 18:11:14 -0400 (EDT) To: Petr Jelinek cc: Alvaro Herrera , PostgreSQL-development Subject: Re: GRANT ON ALL IN schema In-reply-to: <4A8F1986.3030506@pjmodos.net> References: <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> <395.1250439160@sss.pgh.pa.us> <4A8D9CA0.1040607@pjmodos.net> <20090820190604.GK6261@alvh.no-ip.org> <3493.1250864810@sss.pgh.pa.us> <4A8F1986.3030506@pjmodos.net> Comments: In-reply-to Petr Jelinek message dated "Sat, 22 Aug 2009 00:02:46 +0200" Date: Fri, 21 Aug 2009 18:11:14 -0400 Message-ID: <11481.1250892674@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/1518 X-Sequence-Number: 144161 Petr Jelinek writes: > However there is one question about implementing it in plpgsql. > Currently, the compiler reads info directly from heap tuple, so I either > have to write separate compiler for inline functions or change the > existing one to accept the required info as parameters and "fabricate" > some of it when compiling inline function. I am unsure which one is the > preferred way. Sounds like we have to refactor that code a bit. Or maybe it should just be a separate code path. The current plpgsql compiler is also pretty intertwined with stuffing all the information about the function into a persistent memory context, which is something we most definitely *don't* want for an anonymous code block. So it's going to take a bit of work there. I think pulling the heap tuple apart might be the least of your worries. regards, tom lane