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

From Andrew Dunstan
Subject Re: pg_dump/restore encoding woes
Date
Msg-id 521CCFE8.5050604@dunslane.net
Whole thread Raw
In response to Re: pg_dump/restore encoding woes  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On 08/27/2013 11:14 AM, Heikki Linnakangas wrote:
> 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.

Yeah, you're right, I was probably thinking of initdb, although it 
doesn't so much separate these as ignore PGCLIENTENCODING completely.

I guess I'm mainly concerned that we're going to make one of these do 
something different, and it will be hard to remember which is which, at 
least for me (brain cells are no doubt dying at an ever increasing rate 
as I approach my seventh decade.)

cheers

andrew



pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Extension Templates S03E11
Next
From: Heikki Linnakangas
Date:
Subject: Re: Freezing without write I/O