From: | Susanne Ebrecht <susanne(at)2ndQuadrant(dot)com> |
---|---|
To: | Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, 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> |
Subject: | Re: Determining client_encoding from client locale |
Date: | 2011-01-17 13:59:45 |
Message-ID: | 4D344B51.9010401@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 17.01.2011 14:26, Peter Geoghegan wrote:
> On 17 January 2011 12:58, Susanne Ebrecht<susanne(at)2ndquadrant(dot)com> wrote:
>> 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?
> That doesn't tend to be much of a problem in practice because pg_dump
> will have the dump SET client_encoding as appropriate from the DB
> encoding.
Ok, naming it dump.sql was confusing. My fault.
I didn't thought about pg_dump dump files here.
I more thought about files that came out of editors using mad encoding
and maybe then also were created on Windows and then copied to
Unix for import.
Written on little endian, copied to big endian and so on.
Susanne
--
Susanne Ebrecht - 2ndQuadrant
PostgreSQL Development, 24x7 Support, Training and Services
www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2011-01-17 14:01:58 | Re: pg_basebackup for streaming base backups |
Previous Message | Magnus Hagander | 2011-01-17 13:58:22 | Re: Replication logging |