From: | Susanne Ebrecht <susanne(at)2ndQuadrant(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>, Magnus Hagander <magnus(at)hagander(dot)net>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Itagaki Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Subject: | Re: Determining client_encoding from client locale |
Date: | 2011-01-17 12:58:49 |
Message-ID: | 4D343D09.6080600@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14.01.2011 20:12, Peter Eisentraut wrote:
> I have adjusted your old patch for the current tree, and it seems to
> work. I think it was just forgotten last time because the move to
> PQconnectdbParams had to happen first. But I'll throw it back into the
> ring now.
Hello,
maybe i missed pre-discussion but ...
I miss considering auto-detect of file encoding.
A simple example:
$ psql -f dump.sql db
What happens when dump.sql is written by using
another encoding?
I just would expect that when client encoding is detected
by automatism that it also will be detected when I use
files.
My own experience from "the others" is that users
more often forget to think about encoding when they
deal with files as when they type in the client.
Anyway, the code itself seems ok.
I just would recommend to document that the client encoding
should be checked from the user anyway. Just to make sure that
it is not our fault, when there is a libc bug.
Just my 2ct,
Susanne
--
Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-17 13:00:51 | Re: Replication logging |
Previous Message | Robert Haas | 2011-01-17 12:55:15 | Re: texteq/byteaeq: avoid detoast [REVIEW] |