Re: pg_dump/restore encoding woes

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: pg_dump/restore encoding woes
Дата
Msg-id 521CC250.6040101@vmware.com
обсуждение исходный текст
Ответ на Re: pg_dump/restore encoding woes  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: pg_dump/restore encoding woes  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: pg_dump/restore encoding woes
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: changeset generation v5-01 - Patches & git tree