Tom Lane napsal(a): <blockquote cite="mid:11481.1250892674@sss.pgh.pa.us" type="cite"><pre wrap="">Petr Jelinek <a
class="moz-txt-link-rfc2396E"href="mailto:pjmodos@pjmodos.net"><pjmodos@pjmodos.net></a> writes:
</pre><blockquotetype="cite"><pre wrap="">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. </pre></blockquote><pre wrap="">
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. </pre></blockquote><br /> The question is still valid, though it's better put in your words - do we
wantto refactor the existing compiler or write a separate one ?<br /> About putting the information about the function
intoa 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
currentcompiler I was talking about do_compile only (that's why I talked about the heap tuple). It's true that we don't
needmost of the PLpgSQL_function struct for anonymous code block and there might be other advantages in using separate
compilerand exec functions for this.<br /><br /><pre class="moz-signature" cols="72">--
Regards
Petr Jelinek (PJMODOS)</pre>
