9.3 RC1 psql encoding reporting inconsistently?
This is 9.3 RC1 on a Fedora 7 system. Why does \l report the encoding
as SQL_ASCII
and \set report it as UTF8?
psql (9.3rc1)
Type "help" for help.
postgres=# \l
List of databases
Name Owner Encoding Collate Ctype Access privileges
--------- -------- --------- ------- ----- ---------------------
postgres postgres SQL_ASCII C C
template0 postgres SQL_ASCII C C =c/postgres +
postgres=CTc/postgres
template1 postgres SQL_ASCII C C =c/postgres +
postgres=CTc/postgres
(3 rows)
postgres=# \set
AUTOCOMMIT = 'on'
ECHO = 'queries'
PROMPT1 = '%/%R%# '
PROMPT2 = '%/%R%# '
PROMPT3 = '>> '
VERBOSITY = 'default'
VERSION = 'PostgreSQL 9.3rc1 on i686-pc-linux-gnu, compiled by gcc
(GCC) 4.1.2 20070925 (Red Hat 4.1.2-27), 32-bit'
DBNAME = 'postgres'
USER = 'postgres'
PORT = '5432'
ENCODING = 'UTF8'
postgres=#
--
Mike Nolan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Nolan <htfoot@gmail.com> writes:
This is 9.3 RC1 on a Fedora 7 system. Why does \l report the encoding
as SQL_ASCII and \set report it as UTF8?
psql sets client_encoding based on its environment (LANG or related
variables). That's been true for some time --- since 9.1, according
to a quick check.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane-2 wrote
Michael Nolan <
htfoot@
> writes:
This is 9.3 RC1 on a Fedora 7 system. Why does \l report the encoding
as SQL_ASCII and \set report it as UTF8?psql sets client_encoding based on its environment (LANG or related
variables). That's been true for some time --- since 9.1, according
to a quick check.regards, tom lane
My knowledge of encoding is minimal but to expand on the comment:
Client and server (or, more specifically, database) encodings can and often
do differ just as you are seeing here.
I'm guessing that somewhere deep inside psql and/or postgres encoding
conversion is performed if the client and server do not match. While I
guess it is possible to try and auto-adapt the client encoding to match the
server/database the current policy is to require the user to explicitly (so
to speak) declare the encoding they are using on their client.
I guess a counter-question would be: what would you expect "\set" to report
and why?
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/9-3-RC1-psql-encoding-reporting-inconsistently-tp5769334p5769339.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers