From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Vitali Stupin" <Vitali(dot)Stupin(at)ria(dot)ee>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: BUG #2683: spi_exec_query in plperl returns column names which are not marked as UTF8 |
Date: | 2006-10-15 19:02:38 |
Message-ID: | 24559.1160938958@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
unknown_filename | text/plain | 16.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2006-10-15 20:10:54 | Re: BUG #2683: spi_exec_query in plperl returns column names which are not marked as UTF8 |
Previous Message | Greg Sabino Mullane | 2006-10-15 17:34:21 | Re: BUG #2683: spi_exec_query in plperl returns column names which are not marked as UTF8 |
From | Date | Subject | |
---|---|---|---|
Next Message | mark | 2006-10-15 19:07:01 | Re: Postgresql Caching |
Previous Message | mark | 2006-10-15 18:41:46 | Re: Postgresql Caching |