Skip site navigation (1) Skip section navigation (2)

Re: invalid multibyte character for locale

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bjoern Metzdorf <bm(at)turtle-entertainment(dot)de>
Cc: "Pgsql-Admin (E-mail)" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: invalid multibyte character for locale
Date: 2005-02-24 15:15:50
Message-ID: 24832.1109258150@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-hackerspgsql-patches
Bjoern Metzdorf <bm(at)turtle-entertainment(dot)de> writes:
> Is 8.0 just stricter or is this just a side effect 
> of your fix for multibyte upper/lower problem for locale != C?

Both those statements are true.

> If 7.3 and 7.4 behaviour is intended, is there a way to let 8.0 behave 
> the same?

I don't know what behavior you thought you were getting from upper/lower
on UTF-8 data in 7.4, but it was surely not correct.  If you want to
duplicate that misbehavior, try SQL_ASCII with C locale.  This does not
stop you from storing UTF-8 in your database, mind you --- it just
loses validation of encoding sequences and conversion to other schemes.

But having said that, upper() should work if the locale matches the
encoding.  You might take the trouble to trace down exactly what data
value it's barfing on.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-02-24 15:21:16
Subject: Re: [pgsql-hackers-win32] win32 performance - fsync question
Previous:From: Christopher Kings-LynneDate: 2005-02-24 15:02:15
Subject: Re: [pgsql-hackers-win32] win32 performance - fsync question

pgsql-admin by date

Next:From: Scott MarloweDate: 2005-02-24 15:38:00
Subject: Re: Configuration for my server
Previous:From: Marcin GiedzDate: 2005-02-24 14:55:58
Subject: Re: Configuration for my server

pgsql-patches by date

Next:From: Joel FradkinDate: 2005-02-24 16:10:41
Subject: Re: invalid multibyte character for locale
Previous:From: Simon RiggsDate: 2005-02-24 13:24:51
Subject: Re: [PATCHES] A way to let Vacuum warn if FSM settings are low.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group