BUG #6288: Is ALTER ROLE set client_encoding broken in 9.1?
The following bug has been logged online:
Bug reference: 6288
Logged by: Maksym Boguk
Email address: maxim.boguk@gmail.com
PostgreSQL version: 9.1
Operating system: Linux Ubuntu
Description: Is ALTER ROLE set client_encoding broken in 9.1?
Details:
I found common way deal with legacy applications encoding issues through
ALTER ROLE ... set client_encoding '...';
Doesn't work at 9.1 database:
test:
postgres@db13:/home/mboguk$ psql
psql (9.1.1)
Type "help" for help.
postgres=# CREATE DATABASE test WITH TEMPLATE = template0 ENCODING='KOI8R'
LC_COLLATE = 'ru_RU.KOI8-R' LC_CTYPE = 'ru_RU.KOI8-R';
CREATE DATABASE
postgres=# create role test with login;
CREATE ROLE
postgres=# alter role test set client_encoding to 'KOI8R';
ALTER ROLE
postgres=# \q
postgres@db13:/home/mboguk$ psql -U test
psql (9.1.1)
Type "help" for help.
test=> show client_encoding ;
client_encoding
-----------------
UTF8
(1 row)
The same way work without any issues with 8.3 and 8.4.
PS: it's possible i'm missing something obvious.
"Maksym Boguk" <maxim.boguk@gmail.com> writes:
Description: Is ALTER ROLE set client_encoding broken in 9.1?
No, but I think psql prefers to set its encoding according to its locale
enviroment these days.
regards, tom lane
Thank you very much for information. I lost some brain cells during
fighting with that problem yesterday.
However personally I'm think this behavior is rather non-intuitive:
postgres@db13:~$ psql -U slony -d test -c 'show client_encoding'
client_encoding
-----------------
UTF8
(1 row)
postgres@db13:~$ psql -U slony -d test -c 'show client_encoding' | head -10
client_encoding
-----------------
KOI8R
(1 row)
On Fri, Nov 11, 2011 at 1:55 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Maksym Boguk" <maxim.boguk@gmail.com> writes:
Description: Is ALTER ROLE set client_encoding broken in 9.1?
No, but I think psql prefers to set its encoding according to its locale
enviroment these days.regards, tom lane
--
Maxim Boguk
Senior Postgresql DBA.
Skype: maxim.boguk
Jabber: maxim.boguk@gmail.com
LinkedIn profile: http://nz.linkedin.com/in/maximboguk
If they can send one man to the moon... why can't they send them all?
МойКруг: http://mboguk.moikrug.ru/
Сила солому ломит, но не все в нашей жизни - солома, да и сила далеко не все.
Maxim Boguk <maxim.boguk@gmail.com> writes:
However personally I'm think this behavior is rather non-intuitive:
postgres@db13:~$ psql -U slony -d test -c 'show client_encoding'
client_encoding
-----------------
UTF8
(1 row)
postgres@db13:~$ psql -U slony -d test -c 'show client_encoding' | head -10
client_encoding
-----------------
KOI8R
(1 row)
I think psql only pays attention to its locale when stdout is a tty.
Now *why* it acts like that, I'll leave for Peter to defend.
regards, tom lane
On tor, 2011-11-10 at 19:30 -0500, Tom Lane wrote:
I think psql only pays attention to its locale when stdout is a tty.
Now *why* it acts like that, I'll leave for Peter to defend.
We would have to review the original discussion about that. I can see
arguments for doing it that way and for not doing it that way.
This, however, still doesn't explain why a ALTER ROLE ... SET
client_encoding is not taking effect. After all, a plain SET
client_encoding still works.
Peter Eisentraut <peter_e@gmx.net> writes:
On tor, 2011-11-10 at 19:30 -0500, Tom Lane wrote:
I think psql only pays attention to its locale when stdout is a tty.
Now *why* it acts like that, I'll leave for Peter to defend.
We would have to review the original discussion about that. I can see
arguments for doing it that way and for not doing it that way.
This, however, still doesn't explain why a ALTER ROLE ... SET
client_encoding is not taking effect. After all, a plain SET
client_encoding still works.
The ALTER ROLE *does* take effect ... and then psql overrides it from
the environment. Not sure why you expected differently --- psql doesn't
especially care why the server sent the initial client_encoding that it
did.
BTW, I noticed while experimenting with this that if I have an
environment of LANG="C", psql overrides the client_encoding to be
SQL_ASCII, regardless of what the database encoding is. This seems
like a bad idea, since it removes knowledge rather than adding any.
regards, tom lane