> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > I have added new function called "convert" similar to SQL99's convert.
> > Convert converts encoding according to parameters. For example, if you
> > have a table named "unicode" in an Unicode database,
>
> > SELECT convert(text_field, 'LATIN1') FROM unicode;
>
> > will return text in ISO-8859-1 representation.
>
> I don't understand how this works. If you have a multibyte-enabled
> backend, won't backend libpq try to convert all outgoing text to
> whatever PGCLIENTENCODING says? How can it know that one particular
> column of a result set is not in the regular encoding of this database,
> but something else? Seems like libpq is going to mess up the results
> by applying an inappropriate multibyte conversion.
If the encodings of frontend and backend are same, no conversion would
be applied by libpq.
--
Tatsuo Ishii