 | |
Re: [HACKERS] [BUGS] BUG #2683: spi_exec_query in plperl returns
mailing.database.pgsql-bugs mailing.database.pgsql-bugs
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Re: [HACKERS] [BUGS] BUG #2683: spi_exec_query in plperl returns -
10-15-2006
, 05:16 PM
|
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. |
Perl are marked as UTF8; perhaps that makes it happen implicitly?
If not, are there any downsides to issuing "use utf8"?
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly
#2
| |||
| |||
|
|
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. |
in 5.6.
Cheers,
D
--
David Fetter <david (AT) fetter (DOT) org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
#3
| |||
| |||
|
|
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. |
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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
#4
| |||
| |||
|
|
It's clear whether you actually want to allow people to put utf8 characters directly into their source (especially if the database is not in utf8 encoding anyway). There is always the \u{xxxx} escape. |
command anyway. But if it is, then AFAICS the text of pg_proc entries
could be expected to be utf8 too.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
#5
| |||
| |||
|
|
"Andrew Dunstan" <andrew (AT) dunslane (DOT) net> writes: 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. =20 Good question. I took care to ensure that the code strings passed to Perl are marked as UTF8; perhaps that makes it happen implicitly? If not, are there any downsides to issuing "use utf8"? |
what's a valid identifier and such. It doesn't affect the data, for
that you need "use encoding 'utf8'".
It's clear whether you actually want to allow people to put utf8
characters directly into their source (especially if the database is
not in utf8 encoding anyway). There is always the \u{xxxx} escape.
The perlunicode man page describe it better, though I only have
perl5.8. In know the perl5.6 model was different and somewhat more
awkward to use.
Have a nice day,
--=20
Martijn van Oosterhout <kleptog (AT) svana (DOT) org> http://svana.org/kleptog/
Quote:
|
From each according to his ability. To each according to his ability to l= itigate. |
--z6Eq5LdranGa6ru8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFFM5LkIB7bNG8LQkwRAhHAAJ9T24UfiW1Ywvubu3t/yb5CMfws9gCcCkwb
ZHWRrcCqgLPyZ+c1qX9cbM0=
=Jl1g
-----END PGP SIGNATURE-----
--z6Eq5LdranGa6ru8--
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.