PLPERL function error - utf-8 to iso8859-1

[Patrick Hatcher]

Trying to create a plperl function to strip non-friendly mainframe
characters from a string. However, when I try to add the Trademark symbol
(â„¢) as a replace criteria, PG spits back an error:
ERROR: Could not convert UTF-8 to ISO8859-1
Any way I get around this?

CREATE OR REPLACE FUNCTION public.mainfram e_description(v archar)
RETURNS varchar AS
'
my($desc) = @_;
$desc =~ s/®//g;
$desc =~ s/�/e/g;
$desc =~ s/ô/o/g;
$desc =~ s/æ/E/g;
$desc =~ s/Ã’/ /g;
$desc =~ s/Ó/ /g;
$desc =~ s/è/e/g;
$desc =~ s/Ô//g;
$desc =~ s/É/E/g;
$desc =~ s/°//g;
$desc =~ s/é/e/g;
$desc =~ s/~Y//g;
$desc =~ s/Ö//g;
/*Error happens here */
$desc =~ s/â„¢//g;
return $desc;
'
LANGUAGE 'plperl' VOLATILE;
COMMENT ON FUNCTION public.mainfram e_description(v archar) IS 'Return a
clean description for mainframe input';
TIA

Patrick Hatcher

---------------------------(end of broadcast)---------------------------TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match

[Tom Lane]

"Patrick Hatcher" <PH******@macys .com> writes:

Trying to create a plperl function to strip non-friendly mainframe
characters from a string. However, when I try to add the Trademark symbol
(â„¢) as a replace criteria, PG spits back an error:
ERROR: Could not convert UTF-8 to ISO8859-1

AFAICT this means that the trademark symbol is not in the character set
that you've specified to be used in the database; accordingly there's no
need to try to prevent it from being stored...

Perhaps you should have selected the database encoding to be the same as
what you're using on the client side.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

[Patrick Hatcher]

Ah there in lies the problem. I have my database encoding set to LATIN1
and I have this value stored in my table and can even write SQL to search
against it:
select *
from mdc_products
where description ~* '?'

Patrick Hatcher
Macys.Com
Legacy Integration Developer
415-422-1610 office
HatcherPT - AIM

Tom Lane
<tg*@sss.pgh. p To: "Patrick Hatcher" <PH******@macys .com>
a.us> cc: pg***********@p ostgresql.org
Subject: Re: [GENERAL] PLPERL function error - utf-8 to iso8859-1
10/14/2003
09:07 PM

"Patrick Hatcher" <PH******@macys .com> writes:

Trying to create a plperl function to strip non-friendly mainframe
characters from a string. However, when I try to add the Trademark symbol (â"¢) as a replace criteria, PG spits back an error:
ERROR: Could not convert UTF-8 to ISO8859-1

AFAICT this means that the trademark symbol is not in the character set
that you've specified to be used in the database; accordingly there's no
need to try to prevent it from being stored...

Perhaps you should have selected the database encoding to be the same as
what you're using on the client side.

regards, tom lane


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

[Patrick Hatcher]

Ah there in lies the problem. I have my database encoding set to LATIN1
and I have this value stored in my table and can even write SQL to search
against it:
select *
from mdc_products
where description ~* '?'

Patrick Hatcher
Macys.Com
Legacy Integration Developer
415-422-1610 office
HatcherPT - AIM

Tom Lane
<tg*@sss.pgh. p To: "Patrick Hatcher" <PH******@macys .com>
a.us> cc: pg***********@p ostgresql.org
Subject: Re: [GENERAL] PLPERL function error - utf-8 to iso8859-1
10/14/2003
09:07 PM

"Patrick Hatcher" <PH******@macys .com> writes:

Trying to create a plperl function to strip non-friendly mainframe
characters from a string. However, when I try to add the Trademark symbol (â"¢) as a replace criteria, PG spits back an error:
ERROR: Could not convert UTF-8 to ISO8859-1

AFAICT this means that the trademark symbol is not in the character set
that you've specified to be used in the database; accordingly there's no
need to try to prevent it from being stored...

Perhaps you should have selected the database encoding to be the same as
what you're using on the client side.

regards, tom lane


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org