On 01/04/2012 11:15 AM, Tom Lane wrote:
Andrew Dunstan<and...@dunslane.net> writes:
On 01/04/2012 12:47 AM, David E. Wheeler wrote:
Oy, this doesn’t look good:
$ do LANGUAGE plperl $$ elog(NOTICE, $^V) $$;
The connection to the server was lost. Attempting reset: Succeeded.
Try
elog(NOTICE, "$^V")
Isn't this a Perl bug? It seems to be crashing in SvPVutf8, which
means that either Perl passed something that's not an SV to a function
declared to accept SVs, or that SvPVutf8 fails on some SVs. Either
way, Perl is failing to satisfy the POLA if you ask me.
Ummmm, not sure.
The docs (perldoc perlvar) seem to suggest $^V isn't an SV (i.e. a
scalar) but some other sort of animal:
$^V The revision, version, and subversion of the Perl interpreter,
represented as a "version" object.
This variable first appeared in perl 5.6.0; earlier versions of
perl will see an undefined value. Before perl 5.10.0 $^V was
represented as a v-string.
$^V can be used to determine whether the Perl interpreter
executing a script is in the right range of versions. For
example:
warn "Hashes not randomized!\n" if !$^V or $^V lt v5.8.1
To convert $^V into its string representation use "sprintf()"'s
"%vd" conversion:
printf "version is v%vd\n", $^V; # Perl's version
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
