Re: [BUGS] BUG #2683: spi_exec_query in plperl returns - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: [BUGS] BUG #2683: spi_exec_query in plperl returns
Date
Msg-id 20061016141044.GB23302@svana.org
Whole thread Raw
In response to Re: [BUGS] BUG #2683: spi_exec_query in plperl returns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUGS] BUG #2683: spi_exec_query in plperl returns  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Oct 15, 2006 at 06:15:27PM -0400, Tom Lane wrote:
> "Andrew Dunstan" <andrew@dunslane.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.
>
> 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 "use utf8" does is allow the *source* to be in utf8, thus affecting
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,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: Postgresql Caching
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #2683: spi_exec_query in plperl returns