| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump/restore encoding woes |
| Date: | 2013-08-27 15:14:24 |
| Message-ID: | 521CC250.6040101@vmware.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2013-08-27 15:32:30 | Re: changeset generation v5-01 - Patches & git tree |
| Previous Message | Andrew Dunstan | 2013-08-27 15:03:58 | Re: pg_dump/restore encoding woes |