> Tatsuo Ishii <[EMAIL PROTECTED]> 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

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

Reply via email to