doesn't execSRF.c do that already?
| От | Chapman Flack |
|---|---|
| Тема | doesn't execSRF.c do that already? |
| Дата | |
| Msg-id | 5D2D1DBF.60103@anastigmatix.net обсуждение исходный текст |
| Список | pgsql-hackers |
I see some code of long standing in PL/Java where its handler for a set-returning function creates a new context, "PL/Java row context", during first-call init, as a child of context->multi_call_memory_ctx, diligently resets it with every percall-setup and before calling the user function, and deletes it when the whole set has been returned. The more I look at it, the more convinced I am that this is one hundred percent redundant with what ExecMakeTableFunctionResult is already doing with ecxt_per_tuple_memory, which is similarly reset before every call for a tuple, and is already current when PL/Java's handler is called. Am I missing some obvious reason Thomas might have used his own context for that? As far as I can see in git, ExecMakeTableFunctionResult has been providing its own ecxt_per_tuple_memory, at least as far back as 7.3, which I think is (slightly) older than PL/Java. Regards, -Chap
В списке pgsql-hackers по дате отправления: