Re: Client encoding conversion for binary data (was Re: GUC and postgresql.conf docs)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Client encoding conversion for binary data (was Re: GUC and postgresql.conf docs)
Date: 2003-05-15 15:48:50
Message-ID: 9519.1053013730@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-05-15 16:07:30 Re: SET CONSTRAINTS not schema-aware
Previous Message Peter Eisentraut 2003-05-15 15:48:32 Re: SET CONSTRAINTS not schema-aware