Yes, I did.
What have I done.
My Linux version: Debian Etch.
My Postgres version:
"PostgreSQL 8.2.5 on x86_64-unknown-linux-gnu, compiled by GCC gcc
(GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)"
It was compiled by myself.
My initdb was:
initdb -E LATIN1 --locale=pt_BR
By that initdb, the $LANG of the system was pt_BR.UTF-8 .
The pt_BR was not even enabled.
A simple query that shows the problem:
select true AS
"áaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
(it's needed this exact number of chars, with one of them accented.)
The output of the SQL of Alvaro in this server is:
"client_encoding";"UNICODE"
"lc_collate";"pt_BR.UTF-8"
"lc_ctype";"pt_BR.UTF-8"
"lc_messages";"pt_BR"
"lc_monetary";"pt_BR"
"lc_numeric";"pt_BR"
"lc_time";"pt_BR"
"server_encoding";"LATIN1"
(I have enabled the pt_BR locale before the tests, but lc_collate and
lc_type are still pt_BR.UTF-8, due to initdb).
Just after that, I changed my $LANG to pt_BR, did a initdb.
The query
select true AS
"áaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";
returns:
template1-# ;
NOTICE: identifier
"áaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
will be truncated to
"áaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
áaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
On this second initdb:
template1=# select name, setting
template1-# from pg_settings
template1-# where name ~~ any ( array['lc_%', '%_encoding']);
name | setting
-----------------+---------
client_encoding | LATIN1
lc_collate | pt_BR
lc_ctype | pt_BR
lc_messages | pt_BR
lc_monetary | pt_BR
lc_numeric | pt_BR
lc_time | pt_BR
server_encoding | LATIN1
Is that information enough? I can give you more details, if needed.
[]'s
- Walter
---------------------------(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
