Re: BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4
От | Alex Hunsaker |
---|---|
Тема | Re: BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4 |
Дата | |
Msg-id | 34d269d41002190830n7d327878j1ef01a4854639192@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5334: Version 2.22 of Perl Safe module breaks UTF8 PostgreSQL 8.4 (Tim Bunce <Tim.Bunce@pobox.com>) |
Список | pgsql-bugs |
On Fri, Feb 19, 2010 at 06:06, Tim Bunce <Tim.Bunce@pobox.com> wrote: > I've got the patch to Safe ready but the more I think about it the more > I think the right fix is for Safe to automatically fully load utf8.pm > (and utf8_heavy.pl) and to always share SWASHNEW itself. It seems cleaner if we could just share say utf8::VERSION. SWASHNEW seems likely to be changed as it "feels" more like a implementation detail. But if thats what utf8 checks... well then thats what it checks. > Assuming perl5-porters agree then the next release of Safe will do that > ad this patch won't be needed. (Other than it possibly being worthwhile > to detect the 'bad' versions of Safe.) It seems safer if there was some way to 'opt' in say if utf8 was loaded then make safe do the above. Or maybe a pragma? use utf8 qw(utf8); We would still have to patch postgres... But I can imagine there are some users of utf8 that dont want utf8 strings. BTW as I could not reproduce this does this mean that reval->('"\x{}...") works while reval->('sub { "\x{}"}') does not ? Or is it before the first one failed while the closure based one worked?
В списке pgsql-bugs по дате отправления: