Re: Client encoding conversion for binary data (was Re:

Tom Lane writes:

> 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.

Let's look at this in a broader context.  Depending on the data type,
there may be zero, one, or more useful text formats and zero, one, or more
useful binary formats.  The general rule ought to be that text formats are
subject to character set conversion, and the binary formats are not.

For example, the type timestamp might have:

text format "ISO"
text format "German"
binary format "struct tm"
binary format "time_t"

and possibly others.  I would expect the format two to be subject to
character set conversion, but the latter two not.

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.  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.

-- 
Peter Eisentraut   peter_e@gmx.net