| 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 20:42:02 |
| Message-ID: | 1132241.1786999322@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> 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?
Here's a patch to try to clean that up. I think it is wrong that
the extension modules don't use hek2cstr, so I made them do so.
(But we probably shouldn't back-patch that: it's a user-visible
behavioral change and we've not gotten actual field complaints AFAIR.)
> (oh, and for extra credit: why is there a second call of hv_iterinit
> in plperl_build_tuple_result and plperl_modify_tuple?)
That seems to be just cargo-culted, so I removed those calls.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Make-plperl-s-handling-of-Perl-hashes-more-consis.patch | text/x-diff | 7.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2026-08-17 21:54:04 | Re: [Patch] Omit virtual generated columns from test_decoding output |
| Previous Message | Nathan Bossart | 2026-08-17 20:08:55 | Re: problems with toast.* reloptions |