Peter Eisentraut writes:
> Tom Lane wrote:
>> Clients could probably still make use of server_encoding, though I'm
>> unclear on what they'd use it for now, let alone then.  ISTM
>> client_encoding is the only setting the client need deal with directly.

> Then why did we add a GUC variable "server_encoding" at all?

I've just remembered one issue that bears on this subject.  Back around
mid-May we discussed whether "binary" transmission of textual datatypes
ought to perform client<->server encoding conversion or not.  If it does
not, then obviously it would be useful for clients to know what encoding
they are getting.

The current code does perform conversion in these cases.  I think that
when the May thread died off, we were leaning to changing it, but I've
not made it happen yet.

Of course, if we someday support multiple encodings on the server side,
life gets complex --- how would a client know which encoding it's
getting in a binary transmission?  (Perhaps it would have to be part of
the data.)  It doesn't seem like that's a reason to stay with
always-convert, though.  One of the reasons for not doing conversion in
binary mode is to have an escape hatch for unconvertible characters,
eg for dump purposes.  That need will get worse with multiple server
encodings.

			regards, tom lane

Mon, 04 Aug 2003 16:12:17 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Passing server_encoding to the client is not future-proof 
Tom Lane writes:

> One of the reasons for not doing conversion in binary mode is to have an
> escape hatch for unconvertible characters, eg for dump purposes.

That functionality is already provided by setting the client encoding to
SQL_ASCII.

-- 
Peter Eisentraut   peter_e@gmx.net

Wed, 6 Aug 2003 09:57:55 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Passing server_encoding to the client is not future-proof 
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> One of the reasons for not doing conversion in binary mode is to have an
>> escape hatch for unconvertible characters, eg for dump purposes.

> That functionality is already provided by setting the client encoding to
> SQL_ASCII.

Hm.  Okay, so are you arguing that we should not remove encoding
conversion from the binary-transmission case?

			regards, tom lane

Wed, 06 Aug 2003 14:14:25 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Passing server_encoding to the client is not future-proof 
Tom Lane writes:

> Peter Eisentraut <peter_e@gmx.net> writes:
> > Tom Lane writes:
> >> One of the reasons for not doing conversion in binary mode is to have an
> >> escape hatch for unconvertible characters, eg for dump purposes.
>
> > That functionality is already provided by setting the client encoding to
> > SQL_ASCII.
>
> Hm.  Okay, so are you arguing that we should not remove encoding
> conversion from the binary-transmission case?

I think a binary mode for text is pretty useless, at least compared to
binary modes for numbers and other data types, where they are clearly
useful.  Therefore, we should keep the binary mode the same as the normal
mode and just label it "binary".  (I assume it's not practical to not have
a binary mode for particular data types.)

-- 
Peter Eisentraut   peter_e@gmx.net


Sun, 31 Aug 2003 21:09:16 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: Passing server_encoding to the client is not future-proof