On Thu, Feb 25, 2010 at 04:06:51PM -0500, Tom Lane wrote:
> Tim Bunce <Tim.Bunce@pobox.com> writes:
> > On Thu, Feb 25, 2010 at 10:04:44AM -0800, David E. Wheeler wrote:
> >> There seem to be no good answers here.
>
> > There is one fairly good answer:
>
> > Use a perl that's compiled to support multiplicity but not threads.
> > That avoids the sort bug and, as an extra bonus, gives plperl a
> > significant speed boost.
>
> [ scratches head... ] Why would threading have anything to do with the
> security behavior imposed by Safe?
The new security behavior imposed by Safe 2.20+ was added by
Alex to workaround the problem with sort() not seeing $a & $b
in perl built with threads enabled [1]
The extra security was simply a side effect of the workaround.
(And the extra security only applied if threads were enabled.)
So using a perl built without threads is an alternative solution
to the (longstanding) sort bug that might suit some people.
Here's how I see this all working out:
- Safe 2.24 will default to the 2.19 behaviour for closures.
Wrapping of closures will be possible via a new method call.
The utf8 fixes will remain.
- Which means sort() with $a/$b in threaded perls will revert to being broken.
People have got used to that and there are workarounds available
- Someone (not me anytime soon) might work on adding code to
plperl_call_handler(), plperl_validator() etc. to temporarily undo
the Safe restrictions if they're in effect on entry (due to recursion).
As outlined in http://archives.postgresql.org/pgsql-bugs/2010-02/msg00249.php
- Then the plc_safe_ok.pl code could be altered to call the new Safe
method, if available, to wrap the returned closures and thus
re-enable the security features and re-fix the sort() bug.
Tim.
[1] http://rt.perl.org/rt3/Ticket/Display.html?id=60374#txn-627691
