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

From: Roger Leigh <rleigh(at)codelibre(dot)net>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Unicode UTF-8 table formatting for psql text output
Date: 2009-11-14 18:16:54
Message-ID: 20091114181654.GC23762@codelibre.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Nov 14, 2009 at 05:40:24PM +0000, Roger Leigh wrote:
> On Mon, Nov 09, 2009 at 05:40:54PM -0500, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Greg Stark <gsstark(at)mit(dot)edu> writes:
> > > > While i agree this looks nicer I wonder what it does to things like
> > > > excel/gnumeric/ooffice auto-recognizing table layouts and importing
> > > > files. I'm not sure our old format was so great for this so maybe this
> > > > is actually an improvement I'm asking for.
> > >
> > > Yeah. We can do what we like with the UTF8 format but I'm considerably
> > > more worried about the aspect of making random changes to the
> > > plain-ASCII output. On the other hand, we changed that just a release
> > > or so ago (to put in the multiline output in the first place) and
> > > I didn't hear complaints about it that time.
> >
> > Sorry for the delayed reply:
> >
> > The line continuation characters were chosen in 8.4 for clarity --- if
> > you have found something clearer for 8.5, let's make the improvement. I
> > think clarity is more important in this area than consistency with the
> > previous psql output format.
>
> The attached patch is proposed for the upcoming commitfest, and
> hopefully takes into account the comments made in this thread.

One note: because it's not possible to know in advance (without
making things much more complex) whether or not a line will wrap
or continue, the code currently makes sure we fully pad output
up to the right margin of the table (finalspaces). This is in
some cases unnecessary, but is needed when border=1 or else the
continuation/wrap symbols don't end up in the margin and will
look like they are part of the data.

The side effect from this change is that some of the testsuite
expected data will need updating due to the extra pad spaces
now added to the output (triggers, dependency, tsearch,
foreign_data, prepare, with). If the actual output format is
OK with people then I'll update the patch to include the test
data updates as well.

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2009-11-14 18:21:39 Re: Inspection of row types in pl/pgsql and pl/sql
Previous Message Brendan Jurd 2009-11-14 18:12:16 Re: operator exclusion constraints