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
Re: [BUGS] BUG #2683: spi_exec_query in plperl returns |
Список | 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 по дате отправления: