| From: | Chapman Flack <chap(at)anastigmatix(dot)net> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | doesn't execSRF.c do that already? |
| Date: | 2019-07-16 00:43:43 |
| Message-ID: | 5D2D1DBF.60103@anastigmatix.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2019-07-16 01:09:36 | Re: doc: mention pg_reload_conf() in pg_hba.conf documentation |
| Previous Message | Bruce Momjian | 2019-07-16 00:43:08 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |