Re: Anonymous code blocks
От | Petr Jelinek |
---|---|
Тема | Re: Anonymous code blocks |
Дата | |
Msg-id | 4AB8CAC6.2070705@pjmodos.net обсуждение исходный текст |
Ответ на | Re: Anonymous code blocks (Dimitri Fontaine <dfontaine@hi-media.com>) |
Ответы |
Re: Anonymous code blocks
Re: Anonymous code blocks |
Список | pgsql-hackers |
Dimitri Fontaine napsal(a):
It is. I attached patch which does not have this part.
Actually I think we might not need that function memory context for anonymous code blocks at all since we don't cache compiled functions. But I am not sure so I basically copied it from standard function compiler to be on safe side. I am sure commiter will comment on this :)
Hi, Dimitri Fontaine <dfontaine@hi-media.com> writes:Patch applies cleanly and build cleanly too, basic examples are working fine.I've been reading through the code and am going to mark it as ready for commiter, as only remarks I have are probably because I do not know enough about PostgreSQL internals, and the one I missed are in the same category. The patch is easy to read and all it does looks straightforward, even for me :) Here we go: *** a/src/backend/tcop/utility.c --- b/src/backend/tcop/utility.c ... *************** UtilityReturnsTuples(Node *parsetree) *** 1147,1155 **** ... - case T_ExplainStmt: - return true; - Is this not a oversight in the final patch?
It is. I attached patch which does not have this part.
+ /* This is short-lived, so needn't allocate in function's cxt */ + plpgsql_Datums = palloc(sizeof(PLpgSQL_datum *) * datums_alloc); ... + compile_tmp_cxt = MemoryContextSwitchTo(func_cxt); I wonder why not having the datums into the func_cxt too.
Actually I think we might not need that function memory context for anonymous code blocks at all since we don't cache compiled functions. But I am not sure so I basically copied it from standard function compiler to be on safe side. I am sure commiter will comment on this :)
-- Regards Petr Jelinek (PJMODOS)
Вложения
В списке pgsql-hackers по дате отправления: