Re: Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.

Поиск
Список
Период
Сортировка
От Alex Hunsaker
Тема Re: Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.
Дата
Msg-id CAFaPBrT8Na6d-dTV+hmRzZ==6uwdWnQBMpbc3yCMHdiP9emL3w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.  (Amit Khandekar <amit.khandekar@enterprisedb.com>)
Ответы Re: Re: [COMMITTERS] pgsql: Force strings passed to and from plperl to be in UTF8 encoding.
Список pgsql-hackers
On Mon, Oct 3, 2011 at 23:35, Amit Khandekar
<amit.khandekar@enterprisedb.com> wrote:

> WHen GetDatabaseEncoding() != PG_UTF8 case, ret will not be equal to
> utf8_str, so pg_verify_mbstr_len() will not get called. That's the
> reason, pg_verify_mbstr_len() is under the ( ret == utf8_str )
> condition.

Consider a latin1 database where utf8_str was a string of ascii
characters. Then no conversion would take place and ret == utf8_str
but the string would be verified by pg_do_encdoing_conversion() and
verified again by your added check :-).

>> It might be worth adding a regression test also...
>
> I could not find any basic pl/perl tests in the regression
> serial_schedule. I am not sure if we want to add just this scenario
> without any basic tests for pl/perl ?

I went ahead and added one in the attached based upon your example.

Look ok to you?

BTW thanks for the patch!

[ side note ]
I still think we should not be doing any conversion in the SQL_ASCII
case but this slimmed down patch should be less controversial.

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Double sorting split patch
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Double sorting split patch