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 4F04B2E8.1050808@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  (Alex Hunsaker <badalex@gmail.com>)
Re: PL/Perl Does not Like vstrings  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 01/04/2012 12:56 PM, Tom Lane wrote:
> Andrew Dunstan<andrew@dunslane.net>  writes:
>> The docs (perldoc perlvar) seem to suggest $^V isn't an SV (i.e. a
>> scalar) but some other sort of animal:
> Yeah, it's a version object, but I'd have thought that SvPV and friends
> would automatically stringify such an object.  Otherwise, practically
> any kind of perl extension could be crashed by passing it one, no?
>
>> But Util.xs::util_elog() expects an SV and doesn't check whether or not
>> it actually has one. I've found a few other ways of crashing this call
>> (e.g. by passing a typeglob), so maybe we need to test that we actually
>> have an SV. I think SvOK() is what we'd use for that - perl gurus please
>> confirm.
> I looked at that last night but it appeared that SvOK would be perfectly
> happy.  (Didn't actually try it, though, I was just eyeballing the flags
> in gdb.)
>
>             


I tested it and you're right, it doesn't help. I don't see what else we 
can do about it. There doesn't appear to be any test for an SV in the API.

cheers

andrew



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: 16-bit page checksums for 9.2
Next
From: Noah Misch
Date:
Subject: Avoid FK validations for no-rewrite ALTER TABLE ALTER TYPE