From: Chapman Flack <chap@anastigmatix.net>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: doesn't execSRF.c do that already?
Date: Mon, 15 Jul 2019 20:43:43 -0400
Message-ID: <5D2D1DBF.60103@anastigmatix.net> (raw)
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: chap@anastigmatix.net
Subject: Re: doesn't execSRF.c do that already?
In-Reply-To: <5D2D1DBF.60103@anastigmatix.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox