From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "David E(dot) Wheeler" <david(at)justatheory(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PL/Perl Does not Like vstrings |
Date: | 2012-01-04 20:13:28 |
Message-ID: | 4F04B2E8.1050808@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/04/2012 12:56 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2012-01-04 20:24:27 | Avoid FK validations for no-rewrite ALTER TABLE ALTER TYPE |
Previous Message | Robert Haas | 2012-01-04 20:04:48 | Re: 16-bit page checksums for 9.2 |