Tom Lane napsal(a):
Petr Jelinek <pjmo...@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)
