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]  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: info about patch: using parametrised query in psql
Следующее
От: Tim Bunce
Дата:
Сообщение: Re: Update ppport.h in plperl