"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
>> Binary-encoded numeric values don't go through
>> encoding conversion. Text strings currently do. The only place where I
>> had any difficulty deciding what a particular datatype should do is with
>> the 1-byte "char" type, which has a foot in both camps. I decided to
>> treat it as an unconverted single byte (but am willing to listen to
>> argument if anyone thinks differently).
> One concern I would have is how to get at the raw unconverted text data
> without changing the client encoding. I do not really see an advantage in
> providing the same thing for text and binary format if it is now
> a per column thing. I would do text unconverted if binary format is
> selected for that column.
That's a good point: as things currently stand in CVS tip, there's
really no difference between text and binary output of textual
datatypes. Perhaps that's how it should be, but one could make an
argument that we're missing a chance to expose possibly-useful
functionality.
> Did COPY BINARY convert text ?
COPY BINARY currently does the same conversions as binary I/O to the
client. This is arguably reasonable when doing COPY to/from the
frontend, but it's probably not very reasonable when doing COPY to/from
a file in the server's filesystem --- there's no obvious reason why that
should be affected by client_encoding. And yet, I'm not sure the cases
should be different either. Wouldn't it be a bad thing if a COPY dump
made through psql's \copy didn't reload correctly through "COPY FROM
file"?
We could sidestep that issue if binary I/O for text was in server
encoding in all cases.
regards, tom lane