Re: pg_dump/restore encoding woes - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: pg_dump/restore encoding woes
Date
Msg-id 521CC250.6040101@vmware.com
Whole thread Raw
In response to Re: pg_dump/restore encoding woes  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_dump/restore encoding woes  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On 27.08.2013 18:03, Andrew Dunstan wrote:
>
> On 08/27/2013 10:36 AM, Heikki Linnakangas wrote:
>> 0001-Divorce-pg_dump-E-option-from-PGCLIENTENCODING.patch
>>
>> Separates pg_dump -E from PGCLIENTENCODING.
>
> Wouldn't it be better to do this another way? Separating these two will
> be confusing, to say the least, as well as inconsistent with what os
> done elsewhere.

What would it be inconsistent with? There is no -E option in other 
client tools, pg_dump is unique in that. initdb does have a -E option, 
but that *is* separate from PGCLIENTENCODING, so if anything the current 
situation is inconsistent.

> Why not provide a new option that specifically allows a
> client encoding that only applies during the query phase?

Well, that would be different from all the other client programs. And 
doesn't seem any less confusing to me.

- Heikki



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_dump/restore encoding woes
Next
From: Alvaro Herrera
Date:
Subject: Re: changeset generation v5-01 - Patches & git tree