Re: Initial refactoring of plperl.c - rebased [PATCH]
От | Tim Bunce |
---|---|
Тема | Re: Initial refactoring of plperl.c - rebased [PATCH] |
Дата | |
Msg-id | 20091225201602.GC69056@timac.local обсуждение исходный текст |
Ответ на | Re: Initial refactoring of plperl.c - rebased [PATCH] (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Initial refactoring of plperl.c - rebased [PATCH]
|
Список | pgsql-hackers |
On Fri, Dec 25, 2009 at 12:54:13PM -0500, Andrew Dunstan wrote: > Tim Bunce wrote: >> I've attached an update of my previous refactoring of plperl.c. >> It's been rebased over the current (git) HEAD and has a few >> very minor additions. >> > [snip] >> + -- Test compilation of unicode regex >> + -- >> + CREATE OR REPLACE FUNCTION perl_unicode_regex(text) RETURNS INTEGER AS $$ >> + # see http://rt.perl.org/rt3/Ticket/Display.html?id=47576 >> + return ($_[0] =~ /\x{263A}|happy/i) ? 1 : 0; # unicode smiley >> + $$ LANGUAGE plperl; > > This test is failing on my setup at least when the target db is not UTF8 > encoded. > > Maybe that's a bug we need to fix? Yes. I believe the test is highlighting an existing problem: that plperl function in non-PG_UTF8 databases can't use regular expressions that require unicode character meta-data. Either the (GetDatabaseEncoding() == PG_UTF8) test in plperl_safe_init() should be removed, so the utf8fix function is always called, or the test should be removed (or hacked to only apply to PG_UTF8 databases). Tim. p.s. There may be other problems using unicode in non-PG_UTF8 databases, but I believe this patch doesn't change the behaviour for better or worse.
В списке pgsql-hackers по дате отправления: