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
|
Список | 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 по дате отправления: