From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Client encoding conversion for binary data (was Re: GUC and postgresql.conf docs) |
Date: | 2003-05-14 22:44:56 |
Message-ID: | 3906.1052952296@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> writes:
>> We could sidestep that issue if binary I/O for text was in server
>> encoding in all cases.
> I think that would be reasonable, yes. After all one argument for using
> binary mode is speed and efficiency, and not it's editability with
> a text editor.
I just realized that there is a comparable issue for plain-text COPY.
It performs client-to-server encoding conversions in all cases ---
including when reading/writing a file in the server's filesystem.
I think it is correct for plain-text COPY to perform such conversions
when doing COPY to/from the client. I'm much less convinced that it
is sane to apply client_encoding to server-side files. On the other
hand, there's still the point about dumping a file one way and loading
it back the other. Also, it's probably unwise to change this behavior
without a really good argument for doing so, since (AFAIR) we've not
had bug reports about it.
Comments anyone?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | markw | 2003-05-14 22:51:03 | OSDL DBT-2 for PostgreSQL |
Previous Message | Sean Chittenden | 2003-05-14 22:02:36 | Re: LISTEN/NOTIFY benchmarks? |