To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
From: Chapman Flack <chap@anastigmatix.net>
Subject: doesn't execSRF.c do that already?
Message-ID: <5D2D1DBF.60103@anastigmatix.net>
Date: Mon, 15 Jul 2019 20:43:43 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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