From: | David Blewett <david(at)dawninglight(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add encoding support to COPY |
Date: | 2009-07-15 20:19:55 |
Message-ID: | 9d1f8d830907151319u69e5559du6bfc619455bfb265@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 15, 2009 at 4:07 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> David Blewett <david(at)dawninglight(dot)net> writes:
>> On Wed, Jul 15, 2009 at 12:17 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Well, it might make sense to allow an ENCODING option attached to a COPY
>>> with a file source/destination. I remain of the opinion that overriding
>>> client_encoding on a transfer to/from the client is a bad idea.
>
>> I really don't see how it is any different from manually flipping the
>> client_encoding before/after the transfer.
>
> The difference is that the client-side code gets told that the encoding
> changed if you do the latter.
Do you mean at the protocol level?
All I was planning on having the patch do is the equivalent of the set
client_encoding dance. Wouldn't that be sufficent to notify the client
of the encoding change?
David Blewett
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-07-15 20:40:14 | Re: Add encoding support to COPY |
Previous Message | Tom Lane | 2009-07-15 20:07:09 | Re: Add encoding support to COPY |