Thread: 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: =C2=A0 =C2=A0 =C2=A0 =C2=A0Is ALTER ROLE set client_encodin=
g broken in 9.1?
>
> No, but I think psql prefers to set its encoding according to its locale
> enviroment these days.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0regards, tom lane
>



--=20
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?

=D0=9C=D0=BE=D0=B9=D0=9A=D1=80=D1=83=D0=B3: http://mboguk.moikrug.ru/
=D0=A1=D0=B8=D0=BB=D0=B0 =D1=81=D0=BE=D0=BB=D0=BE=D0=BC=D1=83 =D0=BB=D0=BE=
=D0=BC=D0=B8=D1=82, =D0=BD=D0=BE =D0=BD=D0=B5 =D0=B2=D1=81=D0=B5 =D0=B2 =D0=
=BD=D0=B0=D1=88=D0=B5=D0=B9 =D0=B6=D0=B8=D0=B7=D0=BD=D0=B8 - =D1=81=D0=BE=
=D0=BB=D0=BE=D0=BC=D0=B0, =D0=B4=D0=B0 =D0=B8 =D1=81=D0=B8=D0=BB=D0=B0 =D0=
=B4=D0=B0=D0=BB=D0=B5=D0=BA=D0=BE =D0=BD=D0=B5 =D0=B2=D1=81=D0=B5.

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