Re: PL/Perl Does not Like vstrings - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: PL/Perl Does not Like vstrings
Date
Msg-id 4F05B6F2.1000000@dunslane.net
Whole thread Raw
In response to Re: PL/Perl Does not Like vstrings  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PL/Perl Does not Like vstrings
List pgsql-hackers

On 01/04/2012 08:32 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net>  writes:
>> Tom said:
>>> 2. A slightly cleaner fix for this should be to duplicate the SV and
>>> then release the copy around the SvPVutf8 call, only if it's readonly.
>>> "Fixing" it in do_util_elog is entirely the wrong thing.
>> How do we tell if it's readonly?
> SvREADONLY(sv) macro.
>
>             



OK, so this seems to fix The issue David found:

diff --git a/src/pl/plperl/plperl_helpers.h b/src/pl/plperl/plperl_helpers.h
index ac0a97d..f0e1afa 100644
--- a/src/pl/plperl/plperl_helpers.h
+++ b/src/pl/plperl/plperl_helpers.h
@@ -51,7 +51,10 @@ sv2cstr(SV *sv)    /*     * get a utf8 encoded char * out of perl. *note* it may not be 
valid utf8!     */
-   val = SvPVutf8(sv, len);
+   if (SvREADONLY(sv))
+       val = SvPVutf8(sv_mortalcopy(sv), len);
+   else
+       val = SvPVutf8(sv, len);
    /*     * we use perls length in the event we had an embedded null byte to 
ensure



but it doesn't fix the one I found which passes a typeglob to elog():
   do '$foo=1; elog(NOTICE,*foo);' language plperl;


That still crashes, but doesn't if we use sv_mortalcopy unconditionally.


cheers

andrew


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: optimizing repeated MVCC snapshots
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_restore direct to database is broken for --insert dumps