Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id EF2B7635E3B for ; Fri, 21 Aug 2009 19:51:22 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 31327-09 for ; Fri, 21 Aug 2009 22:51:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from phoenix.advel.cz (phoenix.advel.cz [81.0.239.26]) by mail.postgresql.org (Postfix) with SMTP id 739586333D9 for ; Fri, 21 Aug 2009 19:51:11 -0300 (ADT) Received: (qmail 14696 invoked from network); 22 Aug 2009 00:51:08 +0200 Received: from unknown (HELO ?10.12.0.96?) (88.103.48.48) by 192.168.1.50 with SMTP; 22 Aug 2009 00:51:08 +0200 Message-ID: <4A8F24D4.9040801@pjmodos.net> Date: Sat, 22 Aug 2009 00:51:00 +0200 From: Petr Jelinek User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tom Lane CC: Alvaro Herrera , PostgreSQL-development Subject: Re: GRANT ON ALL IN schema 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> <11481.1250892674@sss.pgh.pa.us> In-Reply-To: <11481.1250892674@sss.pgh.pa.us> Content-Type: multipart/alternative; boundary="------------030700000107070504060802" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.598 tagged_above=-10 required=5 tests=AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200908/1522 X-Sequence-Number: 144165 This is a multi-part message in MIME format. --------------030700000107070504060802 Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit Tom Lane napsal(a): > 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. > The question is still valid, though it's better put in your words - do we want to refactor the existing compiler or write a separate one ? About putting the information about the function into a persistent memory context - I was planning on bypassing it and it can be easily bypassed with both implementations, since plpgsql_compile won't be called even if we do the refactoring. When I talked about modifying current compiler I was talking about do_compile only (that's why I talked about the heap tuple). It's true that we don't need most of the PLpgSQL_function struct for anonymous code block and there might be other advantages in using separate compiler and exec functions for this. -- Regards Petr Jelinek (PJMODOS) --------------030700000107070504060802 Content-Type: text/html; charset=windows-1250 Content-Transfer-Encoding: 7bit Tom Lane napsal(a): 
Petr Jelinek <pjmodos@pjmodos.net> 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.

The question is still valid, though it's better put in your words - do we want to refactor the existing compiler or write a separate one ?
About putting the information about the function into a persistent memory context - I was planning on bypassing it and it can be easily bypassed with both implementations, since plpgsql_compile won't be called even if we do the refactoring. When I talked about modifying current compiler I was talking about do_compile only (that's why I talked about the heap tuple). It's true that we don't need most of the PLpgSQL_function struct for anonymous code block and there might be other advantages in using separate compiler and exec functions for this.

-- 
Regards
Petr Jelinek (PJMODOS)
--------------030700000107070504060802--