Re: proposal: psql concise mode - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: proposal: psql concise mode
Date
Msg-id 201111102041.pAAKfgK20514@momjian.us
Whole thread Raw
In response to Re: proposal: psql concise mode  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: proposal: psql concise mode
List pgsql-hackers
Robert Haas wrote:
> On Sun, Nov 6, 2011 at 3:29 PM, Josh Kupershmidt <schmiddy@gmail.com> wrote:
> > On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes <listas@guedesoft.net> wrote:
> >>> test=# \d+ foo
> >>> ? ? ? ? ? ? ? ? ? ? ? ? Table "public.foo"
> >>> ?Column | ?Type ? | Storage
> >>> --------+---------+---------
> >>> ?a ? ? ?| integer | plain
> >>> ?b ? ? ?| integer | plain
> >>> Has OIDs: no
> >>
> >> Using your example, what if column 'b' has a comment and 'a' not? How
> >> the above output will be displayed?
> >
> > Then the comments would be displayed as they previously were, like so:
> >
> > ? ? ? ? ? ? ? ? ? ? ? ? Table "public.foo"
> > ?Column | ?Type ? | Storage | Description
> > --------+---------+---------+-------------
> > ?a ? ? ?| integer | plain ? |
> > ?b ? ? ?| integer | plain ? | some comment
> > Has OIDs: no
> 
> I don't strongly object to this, but I wonder how useful it will
> really be in practice.  It strikes me as the sort of advanced psql
> hackery that only a few people will use, and only some of those will
> gain any benefit.  Empty columns don't really take up that much screen
> width, and even one value in any given column will require its
> inclusion anyway.  I can also see myself turning it on and then going
> - oh, wait, is that column not there, or did it just disappear because
> I'm in concise mode?
> 
> Not saying we shouldn't do it, just some food for thought.

Have you tried \d+ with this psql mode:
\pset format wrapped

It wraps the data so it fits on the screen --- it is my default in my
.psqlrc.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Christopher Browne
Date:
Subject: Re: foreign key locks, 2nd attempt
Next
From: Alvaro Herrera
Date:
Subject: Re: foreign key locks, 2nd attempt