| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> |
| Cc: | andrew(at)dunslane(dot)net, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Residual cleanups for tied objects in PL/Perl |
| Date: | 2026-08-17 15:41:36 |
| Message-ID: | 756684.1786981296@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrey Rachitskiy <pl0h0yp1(at)gmail(dot)com> writes:
> I have attached v2.
v2 looks like a bunch of very random changes. I would like to see
more consistency in the code, ie exactly one pattern for iterating
through hashes and exactly one pattern for iterating through arrays.
We'd not have had the original infinite-loop problem in the first
place if plperl_func_handler() hadn't seen fit to use av_fetch() in a
way randomly different from every other usage. We still have multiple
patterns for iterating through hashes: why do a couple of places use
hv_iternextsv when the others don't? And why do we use hek2cstr
in some places and not others?
(oh, and for extra credit: why is there a second call of hv_iterinit
in plperl_build_tuple_result and plperl_modify_tuple?)
I think we'd be well advised to clean up that inconsistency, and then
inject tied-object handling in the same way in each loop.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ilia Evdokimov | 2026-08-17 15:55:18 | Re: COALESCE patch |
| Previous Message | Bharath Rupireddy | 2026-08-17 15:34:00 | Re: Infinite Autovacuum loop caused by failing virtual generated column expression |