| 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-16 20:26:57 |
| Message-ID: | 579928.1786912017@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:
> A tied hash does not store the value in HeVAL(). hv_iternext() leaves that
> pointer unset. Tom's NULL check therefore always takes the SQL NULL path,
> even when FETCH would return a real value. hv_iterval() plus SvGETMAGIC()
> is what actually runs FETCH.
> The same applies to a tied array. av_len() stops the infinite loop, but
> av_fetch() still returns a magic SV whose SvOK() is false until GETMAGIC.
> Without that, SETOF also yields NULLs.
Hmm. I confirm that adding SvGETMAGIC() makes the tied-array test
work (didn't try the hash case). But to my previous point, where
else would we need to call it, if we're going to try to support
such cases? Also, what exactly are the preconditions for that
function? Looking at the perl header files here, it looks like
sv being nonnull is required and sufficient ... but your patch
is inconsistent about checking that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2026-08-16 21:10:50 | Re: Residual cleanups for tied objects in PL/Perl |
| Previous Message | Daniel Gustafsson | 2026-08-16 20:16:16 | Re: pgcrypto.sgml: built in -> built-in |