From: Petr Jelinek <pjmodos@pjmodos.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: GRANT ON ALL IN schema
Date: Sat, 22 Aug 2009 00:51:00 +0200
Message-ID: <4A8F24D4.9040801@pjmodos.net> (raw)
In-Reply-To: <11481.1250892674@sss.pgh.pa.us>
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>
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)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pjmodos@pjmodos.net, tgl@sss.pgh.pa.us, alvherre@commandprompt.com
Subject: Re: GRANT ON ALL IN schema
In-Reply-To: <4A8F24D4.9040801@pjmodos.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox