Re: Client encoding conversion for binary data (was Re: GUC and postgresql.conf docs) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Client encoding conversion for binary data (was Re: GUC and postgresql.conf docs)
Date
Msg-id 9519.1053013730@sss.pgh.pa.us
Whole thread Raw
In response to Re: Client encoding conversion for binary data (was Re:  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> That same rule applied to character types would say that the "normal" text
> format is subject to character set conversion (of course), and any other
> text format (whatever that would be) would also be.  Any binary format for
> character types would not be subject to character set conversion.  But
> that does not say what would be in that binary format.  It could be the
> internal server encoding representation or mule internal code or the data
> preconverted to the client encoding outside the automatic mechanisms or
> anything else.

True.

> Unless someone can come up with a binary representation
> that would be genuinely useful, the simplest answer would be that
> character types don't have one and you have to use the text format.

You're prejudging the question at hand, which is whether or not access
to the server-encoding representation is useful.  I'm inclined to think
that it is, particularly for backup purposes (no need to worry about
lossage from character set conversions).  Of course one can set
client_encoding equal to server_encoding to get the same effect, but
that doesn't seem to be an argument that it's not useful.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: SET CONSTRAINTS not schema-aware
Next
From: Bruce Momjian
Date:
Subject: Re: SET CONSTRAINTS not schema-aware