Re: [BUGS] BUG #2683: spi_exec_query in plperl returns

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: [BUGS] BUG #2683: spi_exec_query in plperl returns
Дата
Msg-id 2202.24.211.165.134.1160949015.squirrel@www.dunslane.net
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #2683: spi_exec_query in plperl returns column names which are not marked as UTF8  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [BUGS] BUG #2683: spi_exec_query in plperl returns  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [BUGS] BUG #2683: spi_exec_query in plperl returns  (David Fetter <david@fetter.org>)
Список pgsql-hackers
Tom Lane wrote:
> I wrote:
>> It looks to me like basically everywhere in plperl.c that does newSVpv()
>> should follow it with
>>
>> #if PERL_BCDVERSION >= 0x5006000L
>>             if (GetDatabaseEncoding() == PG_UTF8)
>>                 SvUTF8_on(sv);
>> #endif
>
> Experimentation proved that this was insufficient to fix Vitali's
> problem --- the string he's unhappy about is actually a hash key entry,
> and there's no documented way to mark the second argument of hv_store()
> as being a UTF-8 string.  Some digging in the Perl source code found
> that since at least Perl 5.8.0, hv_fetch and hv_store recognize a
> negative key length as meaning a UTF-8 key (ick!!), so I used that hack.
> I am not sure there is any reasonable fix available in Perl 5.6.x.
>
> Attached patch applied to HEAD, but I'm not going to risk back-patching
> it without some field testing.
>

Hmm. That negative pointer hack is mighty ugly.

I am also wondering, now that it's been raised, if we need to issue a "use
utf8;" in the startup code, so that literals in the code get the right
encoding.

cheers

andrew




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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Postgresql Caching
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] BUG #2683: spi_exec_query in plperl returns