Tom Lane wrote:
"Florian Wunderlich" <[EMAIL PROTECTED]> writes:
The following commands are
used in a file encoded in iso-8859-1:
set client_encoding='utf-8';
select upper('äöü');
Isn't that pilot error, plain and simple? You told the machine your
input is in utf8, not latin1.
regards, tom lane
I used iconv to convert the iso-8859-1 to utf-8. This comes a few lines
below those you have quoted.
The file is encoded in iso-8859-1, but contains instructions to set the
client_encoding to utf-8. The whole file is then converted to utf-8
(iconv -f iso-8859-1 -t utf-8 converts from iso-8859-1 to utf-8) and
piped into psql, so this is actually correct.
Besides, if this was the problem, then it should not work with either
database, but it does work with the second database which has iso-8859-1
encoding.
To make this a bit clearer:
SELECT upper(some umlauts) with the same encoding and client_encoding
does not work with a database with encoding='utf-8', but does work with
a database with encoding='iso-8859-1'.
Note that at no point data is actually read from the database; the
upper() function is applied to user supplied input, which is the same
for both databases.
If this is all too confusing I will write a simple test case as bash script.
Thanks for the quick reply,
F. Wunderlich
---------------------------(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
