On Fri, Feb 19, 2010 at 14:00, Tim Bunce <tim.bu...@pobox.com> wrote: > On Fri, Feb 19, 2010 at 09:32:38AM -0700, Alex Hunsaker wrote: >> On Fri, Feb 19, 2010 at 09:18, Alex Hunsaker <bada...@gmail.com> wrote: >> > It seems to me a more correct fix would be to require utf8; inside of >> > the safe like we do strict. >> > .... >> > Id favor this approach as if you have utf8 strings the likely hood >> > that you want ::upgrade, ::downgrade, ::encode, ::valid or ::is_utf8 >> > is fairly high. Then again, no one has complained thus far... Maybe >> > thats just me :) >> >> On second thought, I dont think we should import any of those by >> default. And your hack for just SWASHNEW is better.
Funny.. Safe.pm already does this (share various utf8:: functions) so I think there should be no question that what you did in the patch below is correct and a bug with Safe. Sorry for the handwaves, that was me trying to understand the problem and your fix. :) > Here's the corresponding perlbug > http://rt.perl.org/rt3/Ticket/Display.html?id=72942 Hrm... Is the require utf8; strictly needed? A reading of perldoc utf8 seems to say the do { my $unicode = ... } (aka load utf8_heavy.pl) part should make it all work fine. It also seems to still work t/safeutf8.t ....... ok *shrug* > I'll retest 8.4 and 9.0 against this on Monday. Ill see if I can squeeze in some pg 8.4 perl 5.10.1 linux x86_64 testing tonight of the above. (Ill just reply to the perl bug ) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
