On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote:
> Roger Leigh <rleigh@codelibre.net> writes:
> > On Sun, Oct 04, 2009 at 11:22:27PM +0300, Peter Eisentraut wrote:
> >> Elsewhere in the psql code, notably in mbprint.c, we make the decision
> >> on whether to apply certain Unicode-aware processing based on whether
> >> the client encoding is UTF8. The same should be done here.
> >>
> >> There is a patch somewhere in the pipeline that would automatically set
> >> the psql client encoding to whatever the locale says, but until that is
> >> done, the client encoding should be the sole setting that rules what
> >> kind of character set processing is done on the client side.
>
> > OK, that makes sense to a certain extent. However, the characters
> > used to draw the table lines are not really that related to the
> > client encoding for data sent from the database (IMHO).
>
> Huh? The data *in* the table is going to be in the client_encoding, and
> psql contains no mechanisms that would translate it to something else.
> Surrounding it with decoration in a different encoding is just a recipe
> for breakage.
Ah, I was under the mistaken assumption that this was iconv()ed or
otherwise translated for correct display. In that case, I'll leave
the patch as is (using the client encoding for table lines).
I've attached an updated copy of the patch (it just removes the
now unneeded langinfo.h header).
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
