Thread: proposal: psql concise mode
Hi all, The good news is that psql's backslash commands are becoming quite thorough at displaying all information which could conceivably be of interest about an object. The bad news is, psql's backslash commands often produce a lot of noise and wasted output. (There was some grumbling along these lines re: the recent Stats Target patch). I'd like to propose a "concise mode" for psql, which users might turn on via a \pset option. Concise mode would affect only the output of psql's backslash commands. For output results which have some all-NULL columns, as in: test=# \d+ foo Table "public.foo"Column | Type | Modifiers | Storage | Stats target | Description --------+---------+-----------+---------+--------------+-------------a | integer | | plain | |b | integer | | plain | | Has OIDs: no Concise mode would simply omit the all-NULL columns, so that the output would look like this: test=# \d+ foo Table "public.foo"Column | Type | Storage --------+---------+---------a | integer | plainb | integer | plain Has OIDs: no For actually implementing this: it'd be nice if the changes could be localized to printQuery(). Unfortunately, there are a few stragglers such as describeOneTableDetails() which have their own notions about how to print their output, so I'm not sure how straightforward/small such a patch would be. But I just wanted to throw the idea out there. Any thoughts? Josh
2011/11/5 Josh Kupershmidt <schmiddy@gmail.com>: > I'd like to propose a "concise mode" for psql, which users might turn > on via a \pset option. Concise mode would affect only the output of > psql's backslash commands. For output results which have some all-NULL > columns, as in: > > test=# \d+ foo > Table "public.foo" > Column | Type | Modifiers | Storage | Stats target | Description > --------+---------+-----------+---------+--------------+------------- > a | integer | | plain | | > b | integer | | plain | | > Has OIDs: no > > Concise mode would simply omit the all-NULL columns, so that the > output would look like this: > > 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? -- Dickson S. Guedes mail/xmpp: guedes@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br
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
Josh
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, Nov 7, 2011 at 10:04 PM, Robert Haas <robertmhaas@gmail.com> wrote: > 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. I'm probably just not going to bother, based on the (lack of) response so far. I'd like to have it for myself, but not enough to make the patch and then fight for its inclusion :-) > Empty columns don't really take up that much screen > width, and even one value in any given column will require its > inclusion anyway. What really prompted the proposal was my somewhat antiquated use of 80-column terminal windows (so that 2 or 3 fit side-by-side comfortably on my screen). A lot of the backslash commands are creeping well over that 80-column limit, even with the most basic of outputs, and I find the default line-wrapping hard to follow. And I'd bet that the use of column comments and column statistics targets, for example, are quite rare -- and that's almost 30 columns of horizontal space lost for the common case of \d+ tablename. Maybe I just have to get comfortable with the "expanded" mode. > 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? Yeah, that would be a bit of a nuisance in some cases. > Not saying we shouldn't do it, just some food for thought. Thanks for the feedback, anyway. Josh
On Mon, Nov 7, 2011 at 11:01 PM, Josh Kupershmidt <schmiddy@gmail.com> wrote: > What really prompted the proposal was my somewhat antiquated use of > 80-column terminal windows (so that 2 or 3 fit side-by-side > comfortably on my screen). A lot of the backslash commands are > creeping well over that 80-column limit, even with the most basic of > outputs, and I find the default line-wrapping hard to follow. And I'd > bet that the use of column comments and column statistics targets, for > example, are quite rare -- and that's almost 30 columns of horizontal > space lost for the common case of \d+ tablename. Yeah, I've noticed that, too. OTOH, the regular old \d output, as opposed to \d+, still fits fairly well. Mostly. So I'm managing. But I can't help feeling that as we continue to add more features, we've eventually going to end up with our backs to the wall. Not sure what to do about that, but... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Excerpts from Robert Haas's message of mar nov 08 01:25:31 -0300 2011:
> But I can't help feeling that as we continue to add more features,
> we've eventually going to end up with our backs to the wall. Not sure
> what to do about that, but...
What I've imagined for a long time is psql being able to display each
row in more than one line; for example something like
\df
Listado de funcionesEsquema | Nombre | Tipo de dato de salida | TipoTipos de datos de
argumentos
---------+-------------------+------------------------+--------------------------------------------------------------------------------------public
| bt_metap | record | normalrelname text, OUT magic integer, OUT version integer, OUT root
integer,OUT level integer, OUT fastroot integer, OUT fastlevel integer
---------+-------------------+------------------------+--------------------------------------------------------------------------------------public
| bt_page_items | SETOF record | normalrelname text, blkno integer, OUT itemoffset smallint, OUT ctid
tid,OUT itemlen smallint, OUT nulls boolean, OUT vars boolean, OUT data text
---------+-------------------+------------------------+--------------------------------------------------------------------------------------
So it's not as horizontally-wasteful as expanded, but it's much more
readable than aligned.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
2011/11/8 Alvaro Herrera <alvherre@commandprompt.com>: > What I've imagined for a long time is psql being able to display each > row in more than one line; for example something like > > \df > > Listado de funciones > Esquema | Nombre | Tipo de dato de salida | Tipo > Tipos de datos de argumentos > ---------+-------------------+------------------------+-------------------------------------------------------------------------------------- > public | bt_metap | record | normal > relname text, OUT magic integer, OUT version integer, OUT root integer, OUT level integer, OUT fastroot integer, OUT fastlevelinteger > ---------+-------------------+------------------------+-------------------------------------------------------------------------------------- > public | bt_page_items | SETOF record | normal > relname text, blkno integer, OUT itemoffset smallint, OUT ctid tid, OUT itemlen smallint, OUT nulls boolean, OUT varsboolean, OUT data text > ---------+-------------------+------------------------+-------------------------------------------------------------------------------------- Isn't that what pagers like 'less' and 'more' do already? May be we could provide a pager more specific to psql output as a contrib or extension. []s -- Dickson S. Guedes mail/xmpp: guedes@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br
Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011: > Isn't that what pagers like 'less' and 'more' do already? May be we > could provide a pager more specific to psql output as a contrib or > extension. Well, now that you mention it, all pagers I know are line-based. If you want to figure out how to make a pager that's record-based instead, be my guest. It sounds very useful for this sort of use case. Nice to see you in PGBR by the way. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
2011/11/8 Alvaro Herrera <alvherre@commandprompt.com>: > Excerpts from Dickson S. Guedes's message of mar nov 08 12:11:21 -0300 2011: >> Isn't that what pagers like 'less' and 'more' do already? May be we >> could provide a pager more specific to psql output as a contrib or >> extension. > > Well, now that you mention it, all pagers I know are line-based. If you > want to figure out how to make a pager that's record-based instead, be > my guest. It sounds very useful for this sort of use case. Yes, it could be a good homework for me to do later, then I'll wait for more opinions about the original Josh's proposal to avoid duplicate work. > Nice to see you in PGBR by the way. Nice to see you too! :) Best regards. -- Dickson S. Guedes mail/xmpp: guedes@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br
On Mon, Nov 7, 2011 at 11:25 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> But I can't help feeling that as we continue to add more features,
> we've eventually going to end up with our backs to the wall. Not sure
> what to do about that, but...
Seriously, parts of psql are starting to become a real mess.
[tangentially related rant]
I cringe whenever I have to go digging around in describe.c.
describeOneTableDetails() is what, 1100+ lines?! Doubtless, some
refactoring of that function would help. But the
backwards-compatibility burden isn't helping the situation. The first
conditional block based on pset.sversion in that function contains:
... else if (pset.sversion >= 80000) {
[some query against pg_catalog.pg_class] } else { printfPQExpBuffer(&buf, "SELECT
relchecks,relkind, relhasindex, relhasrules, " "reltriggers <> 0, relhasoids, "
"'', ''\n" "FROM pg_catalog.pg_class WHERE oid = '%s';", oid);
}
We're essentially pretending that we support all server versions with
this code, instead of erroring out on some definite old version and
admitting "sorry, can't do it". The latter query would really break on
a 7.1 [*] or earlier server (thanks to "relhasoids"). Other pieces of
the same function would fail on 7.2 or earlier, e.g. due to querying
pg_depend or pg_namespace. Other code will fail on 7.3 or earlier,
e.g. due to querying pg_user.
I think we should draw a line somewhere about just how far back psql
must support, and don't worry about having crufty "maybe it works but
who knows exactly how far back" code for further support than that. I
think 8.0 would be a very generous backwards compatibility target.
Josh
--
[*] I based these claims about how far back the code would actually
work based on perusing old catalog doc pages, like:
http://www.postgresql.org/docs/7.3/static/catalogs.html
It's possible some of the old doc pages are incorrect, but I think my
point still stands.
Josh Kupershmidt <schmiddy@gmail.com> writes:
> We're essentially pretending that we support all server versions with
> this code, instead of erroring out on some definite old version and
> admitting "sorry, can't do it". ...
> I think we should draw a line somewhere about just how far back psql
> must support,
Says right at the top of the file:
* Support for the various \d ("describe") commands. Note that the current* expectation is that all functions in this
filewill succeed when working* with servers of versions 7.4 and up. It's okay to omit irrelevant* information for an
oldserver, but not to fail outright.
regards, tom lane
[Sorry for not CC'ing the list before, I'm still getting used to the
new Gmail interface]
On Tue, Nov 8, 2011 at 11:05 PM, Josh Kupershmidt <schmiddy@gmail.com> wrote:
> On Tue, Nov 8, 2011 at 10:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Josh Kupershmidt <schmiddy@gmail.com> writes:
>>> We're essentially pretending that we support all server versions with
>>> this code, instead of erroring out on some definite old version and
>>> admitting "sorry, can't do it". ...
>>> I think we should draw a line somewhere about just how far back psql
>>> must support,
>>
>> Says right at the top of the file:
>>
>> * Support for the various \d ("describe") commands. Note that the current
>> * expectation is that all functions in this file will succeed when working
>> * with servers of versions 7.4 and up. It's okay to omit irrelevant
>> * information for an old server, but not to fail outright.
>
> Oh, heh, I did miss that note. 7.4 is a reasonable target, I guess.
> It's not clear to me from that comment whether it's acceptable for the
> code to "fail outright" on servers older than 7.4, as in the snippet I
> posted, but I'm pretty sure that is what would happen. (I don't have a
> 7.x install handy to test that theory, as I haven't been able to build
> anything older than 8.0.)
FWIW, I just played around with 7.4 and 7.3 servers. (I had some bad
memories of the older tarballs not building, but that must have been
only on OS X -- I can build at least back to 7.3 on this Ubuntu 11.04
machine.)
Most meta-commands worked alright on 7.4, or at least failed
gracefully. The ones I saw which failed unexpectedly were \sf and \ef,
which complained:
ERROR: function pg_catalog.pg_get_functiondef(integer) does not exist
I think we need a server version check for these two meta-commands,
unless someone cares to make them work on < 8.4, trivial patch
attached.
As I suggested, many more unexpected failures (e.g. \dnS+) pop up when
talking to a 7.3 server. It's not a big deal, but it'd be nice if we
could instead error out with a "sorry, we're too lazy to try to
support 7.3" on the meta-commands which fail thusly, and make the
various "else" clauses more explicit about just how far back their
support really goes.
Josh
Attachment
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. +
Josh Kupershmidt <schmiddy@gmail.com> writes:
> FWIW, I just played around with 7.4 and 7.3 servers. (I had some bad
> memories of the older tarballs not building, but that must have been
> only on OS X -- I can build at least back to 7.3 on this Ubuntu 11.04
> machine.)
> Most meta-commands worked alright on 7.4, or at least failed
> gracefully. The ones I saw which failed unexpectedly were \sf and \ef,
> which complained:
> ERROR: function pg_catalog.pg_get_functiondef(integer) does not exist
> I think we need a server version check for these two meta-commands,
> unless someone cares to make them work on < 8.4, trivial patch
> attached.
Agreed, we should check that. Will commit.
> As I suggested, many more unexpected failures (e.g. \dnS+) pop up when
> talking to a 7.3 server. It's not a big deal, but it'd be nice if we
> could instead error out with a "sorry, we're too lazy to try to
> support 7.3" on the meta-commands which fail thusly, and make the
> various "else" clauses more explicit about just how far back their
> support really goes.
Probably not worth the trouble ... how many pre-7.4 servers are still in
the wild, and of those, how many might somebody try to talk to with a
modern psql?
The more realistic direction of future change, I think, is that we move
up the cutoff version so we can take out some code, rather than add
more. At the moment I'd find it a hard sell to drop support for 8.1 or
later; so maybe there's not enough removable code to make it worth any
effort. But in a few more years it'd be worth doing.
What *would* be worth doing today, IMO, is ripping out pg_dump's support
for servers older than 7.3 or 7.4; in particular getting rid of its
kluges for server versions without pg_depend info.
regards, tom lane
On Thu, Nov 10, 2011 at 3:41 PM, Bruce Momjian <bruce@momjian.us> wrote:
> 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.
I think that's one of the many psql features I haven't experimented
with, thanks for the suggestion. It looks OK for some things, but I
find the column-wrapping behavior can be rather illegible, e.g.
create table test ( some_column_name serial PRIMARY KEY, another_column_name integer NOT NULL, another_col integer,
usernametext
);
tmp=# \d+ test Table "public.test" Column | Type | Modifiers | Storage | Stats
target| Description
----------------+---------+--------------+---------+--------------+-------------some_column_na.| integer | not null
def.|plain | |
.me | |.ault nextval.| | | | |.('test_some_.| |
| | |.column_name_.| | | | |.seq'::regcla.|
| | | |.ss) | | |another_column.| integer | not
null | plain | |
._name | | | | |another_col | integer | | plain |
|username | text | | extende.| | | |
|.d | |
That wrapping is pretty ugly, and the culprit is all the wasted
horizontal space for "Stats Target" and "Description" in this case
(and probably for many users, who never set either column modifier).
That output might be much nicer if, instead of "Modifiers", "Column",
and "Storage" getting squeezed, the empty "Stats Target" and
"Description" column headers got squeezed instead, giving the
populated columns more horizontal space.
On Thu, Nov 10, 2011 at 6:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> As I suggested, many more unexpected failures (e.g. \dnS+) pop up when >> talking to a 7.3 server. It's not a big deal, but it'd be nice if we >> could instead error out with a "sorry, we're too lazy to try to >> support 7.3" on the meta-commands which fail thusly, and make the >> various "else" clauses more explicit about just how far back their >> support really goes. > > Probably not worth the trouble ... how many pre-7.4 servers are still in > the wild, and of those, how many might somebody try to talk to with a > modern psql? > > The more realistic direction of future change, I think, is that we move > up the cutoff version so we can take out some code, rather than add > more. At the moment I'd find it a hard sell to drop support for 8.1 or > later; so maybe there's not enough removable code to make it worth any > effort. But in a few more years it'd be worth doing. I am 100% on board with dropping support for such old servers whenever feasible, so as to cut down on the cruft in psql -- that's the only reason I cared to go poking at this at all. I would suggest we bump the minimum supported server version for psql up to 8.0 at some point in the not-too-distant future, perhaps even for 9.2. > What *would* be worth doing today, IMO, is ripping out pg_dump's support > for servers older than 7.3 or 7.4; in particular getting rid of its > kluges for server versions without pg_depend info. Yeah, that was another can of worms I had in the back of my mind. I think there's a good case for maintaining longer backwards compatibility in pg_dump vs. psql, to help people upgrade an ancient server to a modern one. But certainly, anything older than 7.3 or 7.4 is pushing the boundaries in terms of being supported. Jsoh
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10-11-2011 21:42, Josh Kupershmidt wrote:
> On Thu, Nov 10, 2011 at 3:41 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> 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.
>
> I think that's one of the many psql features I haven't experimented
> with, thanks for the suggestion. It looks OK for some things, but I
> find the column-wrapping behavior can be rather illegible, e.g.
>
> create table test (
> some_column_name serial PRIMARY KEY,
> another_column_name integer NOT NULL,
> another_col integer, username text
> );
>
> tmp=# \d+ test
> Table "public.test"
> Column | Type | Modifiers | Storage | Stats target | Description
> ----------------+---------+--------------+---------+--------------+-------------
> some_column_na.| integer | not null def.| plain | |
> .me | |.ault nextval.| | |
> | |.('test_some_.| | |
> | |.column_name_.| | |
> | |.seq'::regcla.| | |
> | |.ss) | | |
> another_column.| integer | not null | plain | |
> ._name | | | | |
> another_col | integer | | plain | |
> username | text | | extende.| |
> | | |.d | |
>
>
>
> That wrapping is pretty ugly, and the culprit is all the wasted
> horizontal space for "Stats Target" and "Description" in this case
> (and probably for many users, who never set either column modifier).
> That output might be much nicer if, instead of "Modifiers", "Column",
> and "Storage" getting squeezed, the empty "Stats Target" and
> "Description" column headers got squeezed instead, giving the
> populated columns more horizontal space.
I'm not convinced yet, because a single comment in only one column is
enough to show the "Description"'s column again.
IMHO it seems to me that the only gain of this new proposed behaviour
only happens when there is no especial information about the columns,
like comments or stat target, and I don't know if this is a common
situation.
[]s
- --
Dickson S. Guedes
mail/xmpp: guedes@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
http://github.net/guedes - twitter: @guediz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOvGpeAAoJEBa5zL7BI5C7V6cH/3chliawlBO0Sf0HB2DSmHeK
AyfA+LPiKRa9Egnlt7jHIAqdiplVkfUkaP8P2L2OryexStb8eXtAWeRJjHdR11di
X15M6551vHf7fqwmCpHtNebACXDdrQefHuw9MFtPYe4jaJwy1kU7IyLQcpRjNA0s
mvPJKrH08WqdFIw0DgiZi1+EFZE2Swr/zAKbNU2snGhKA0w2juHpoBOHmlfxmXQq
Z2zWvins8nqG1lpAhhD1QZzImGpWf/W7hiXDoP2BGo9wYjU38obbVdZJHNAey75B
9C4f75vQH4MRGy/wWYEPxttLoBerQaVedfEFPyHIOoqUOpIMJeLLqbk6mY5AIDM=
=5Oez
-----END PGP SIGNATURE-----
On Mon, Nov 07, 2011 at 11:01:39PM -0500, Josh Kupershmidt wrote: > On Mon, Nov 7, 2011 at 10:04 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > > 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? > > Yeah, that would be a bit of a nuisance in some cases. Well, that specific problem could be fixed with some format signalling, such as changing the vertical divider, or perhaps leaving it doubled: Given your test case: test=# \d+ foo Table "public.foo" Column | Type | Modifiers | Storage | Stats target | Description--------+---------+-----------+---------+--------------+-------------a | integer | | plain | | b | integer | | plain | |Has OIDs: no Concise output might look like (bikeshed argument: "splat" indicates columns "squashed" out):test=# \d+ foo Table "public.foo" Column | Type # Storage #--------+---------+---------+a | integer # plain # b | integer # plain #Has OIDs: no or: Column | Type || Storage |--------+---------++---------+ a | integer || plain | b | integer || plain | or even: Column | Type || Storage ||--------+---------++---------++ a | integer || plain || b | integer ||plain || Ross -- Ross Reedstrom, Ph.D. reedstrm@rice.edu Systems Engineer & Admin, Research Scientist phone: 713-348-6166 Connexions http://cnx.org fax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE
On Mon, Nov 14, 2011 at 5:16 PM, Ross Reedstrom <reedstrm@rice.edu> wrote: > Concise output might look like (bikeshed argument: "splat" indicates > columns "squashed" out): > > test=# \d+ foo > Table "public.foo" > Column | Type # Storage # > --------+---------+---------+ > a | integer # plain # > b | integer # plain # > Has OIDs: no > > or: > > Column | Type || Storage | > --------+---------++---------+ > a | integer || plain | > b | integer || plain | > > or even: > > Column | Type || Storage || > --------+---------++---------++ > a | integer || plain || > b | integer || plain || Yeah, that's an idea. And/or the table footer could list the omitted columns. Josh