Unicode UTF-8 table formatting for psql text output
in [PgSql]
|
Prev: Hot Standby 0.2.1
Next: Rejecting weak passwords
From: Andrew Dunstan on 31 Oct 2009 15:27 Roger Leigh wrote: > On Sat, Oct 31, 2009 at 12:25:22PM -0400, Andrew Dunstan wrote: > >> Roger Leigh wrote: >> >>> Wouldn't it be much simpler all around to add a "csv" output format >>> in addition to the above for this purpose? Spreadsheets can read >>> it in with no trouble at all. >>> >> We've had CSV output since version 8.0. >> > > Really? The only references I see are in tab-complete.c relating to > COPY. > > You can set the field separator to ',' but you can't do a > \pset format csv > and get CSV with correct quoting, escaping etc AFAICS. It'll > still break on line wrapping if wrapping is enabled, and with > newlines in the data. > > If that would be a useful addition, I can add it. > > > > It's done by the backend, not by psql, but it has psql support - see \copy cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 9 Nov 2009 17:52 Andrew Dunstan wrote: > >You can set the field separator to ',' but you can't do a > > \pset format csv > >and get CSV with correct quoting, escaping etc AFAICS. It'll > >still break on line wrapping if wrapping is enabled, and with > >newlines in the data. > > > >If that would be a useful addition, I can add it. > > It's done by the backend, not by psql, but it has psql support - see \copy I agree with Roger that we should really have a CSV option in \pset format. COPY as CVS is certainly very useful, but it's a different use case. (You can't \copy a \-command for example). -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Roger Leigh on 14 Nov 2009 12:40 On Mon, Nov 09, 2009 at 05:40:54PM -0500, Bruce Momjian wrote: > Tom Lane wrote: > > Greg Stark <gsstark(a)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. To summarise the changes: - it makes the handling of newlines and wrapped lines consistent between column header and data lines. - it includes additional logic such that both the "old" and "new" styles are representable using the format structures, so we can retain backward compatibility if so desired (it's easy to remove if not). - an "ascii-old" linestyle is added which is identical to the old style for those who need guaranteed reproducibility of output, but this is not the default. - The Unicode format uses "âµ" in the right-hand margin to indicate newlines. Wrapped lines use "â¦" in the right-hand margin before, and left-hand margin after, a break (so you can visually follow the wrap). - The ASCII format is the same but uses "+" and "." in place of carriage return and ellipsis symbols. - All the above is documented in the SGML documentation, including the old style, which I always found confusing. For comparison, I've included a transcript of all three linestyles with a test script (also attached). Any changes to the symbols used and/or their placement are trivially made by just altering the format in print.c. 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.
From: Roger Leigh on 14 Nov 2009 13:16 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(a)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.
From: Tom Lane on 14 Nov 2009 13:31
Roger Leigh <rleigh(a)codelibre.net> writes: > The side effect from this change is that some of the testsuite > expected data will need updating due to the extra pad spaces No, we are *not* doing that. Somebody made a change to the print.c logic last year that started adding "harmless" white space to the last column, and it was a complete disaster for tracking whether anything important had changed in regression test output. Please undo that part of your patch. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |