Re: Unicode UTF-8 table formatting for psql text output - Mailing list pgsql-hackers

From Roger Leigh
Subject Re: Unicode UTF-8 table formatting for psql text output
Date
Msg-id 20091114181654.GC23762@codelibre.net
Whole thread Raw
In response to Re: Unicode UTF-8 table formatting for psql text output  (Roger Leigh <rleigh@codelibre.net>)
Responses Re: Unicode UTF-8 table formatting for psql text output
List 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@mit.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. 

pgsql-hackers by date:

Previous
From: Brendan Jurd
Date:
Subject: Re: operator exclusion constraints
Next
From: "Florian G. Pflug"
Date:
Subject: Re: Inspection of row types in pl/pgsql and pl/sql