Re: Unicode UTF-8 table formatting for psql text output

From: "Brad T(dot) Sliger" <brad(at)sliger(dot)org>
To: Roger Leigh <rleigh(at)codelibre(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Selena Deckelmann <selenamarie(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Roger Leigh <rleigh(at)debian(dot)org>
Subject: Re: Unicode UTF-8 table formatting for psql text output
Date: 2009-10-07 21:18:58
Message-ID: 200910071418.59351.brad@sliger.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tuesday 06 October 2009 11:35:03 Roger Leigh wrote:
> On Tue, Oct 06, 2009 at 10:44:27AM +0100, Roger Leigh wrote:
> > On Mon, Oct 05, 2009 at 04:32:08PM -0400, Tom Lane wrote:
> > > Roger Leigh <rleigh(at)codelibre(dot)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).
>
> This patch included a bit of code not intended for inclusion
> (setting of client encoding based on locale), which the attached
> (and hopefully final!) revision of the patch excludes.
>
>
> Regards,
> Roger

I looked at psql-utf8-table-9.patch.

It applies, builds and installs. `gmake check` passes and is not affected by values of LANG or LC_ALL in the
environment. HTML and man documentation builds and looks good. The patch doesn't introduce new lint.

The psql utility displays UTF8 line art when the client encoding is UTF8, and ASCII line art is displayed otherwise.
This can be overridden with `\pset linestyle ASCII` or `\pset linestyle UTF8`. The psql line art is no longer affected by
the values of LANG or LC_ALL in the environment.

As far as I can tell, everything looks reasonable.

Thanks,

--bts

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marko Tiikkaja 2009-10-07 21:20:20 Re: Writeable CTEs and side effects
Previous Message Jaime Casanova 2009-10-07 21:16:20 Re: Writeable CTEs and side effects