Re: [HACKERS] proposal: psql concise mode
On Mon, Nov 07, 2011 at 11:01:39PM -0500, Josh Kupershmidt wrote: On Mon, Nov 7, 2011 at 10:04 PM, Robert Haas robertmh...@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. reeds...@rice.edu Systems Engineer Admin, Research Scientistphone: 713-348-6166 Connexions http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
On Mon, Nov 14, 2011 at 5:16 PM, Ross Reedstrom reeds...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
Robert Haas wrote: On Sun, Nov 6, 2011 at 3:29 PM, Josh Kupershmidt schmi...@gmail.com wrote: On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes lis...@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 br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
Josh Kupershmidt schmi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
On Thu, Nov 10, 2011 at 3:41 PM, Bruce Momjian br...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
On Thu, Nov 10, 2011 at 6:12 PM, Tom Lane t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
-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 br...@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: gue...@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- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
[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 schmi...@gmail.com wrote: On Tue, Nov 8, 2011 at 10:04 PM, Tom Lane t...@sss.pgh.pa.us wrote: Josh Kupershmidt schmi...@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 diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 2c38902..121612c 100644 *** a/src/bin/psql/command.c --- b/src/bin/psql/command.c *** exec_command(const char *cmd, *** 583,589 { int lineno = -1; ! if (!query_buf) { psql_error(no query buffer\n); status = PSQL_CMD_ERROR; --- 583,595 { int lineno = -1; ! if (pset.sversion 80400) ! { ! psql_error(The server (version %d.%d) does not support editing function source.\n, ! pset.sversion / 1, (pset.sversion / 100) % 100); ! status = PSQL_CMD_ERROR; ! } ! else if (!query_buf) { psql_error(no query buffer\n); status = PSQL_CMD_ERROR; *** exec_command(const char *cmd, *** 1115,1121 func_buf = createPQExpBuffer(); func = psql_scan_slash_option(scan_state, OT_WHOLE_LINE, NULL, true); ! if (!func) { psql_error(function name is required\n); status = PSQL_CMD_ERROR; --- 1121,1133 func_buf = createPQExpBuffer(); func = psql_scan_slash_option(scan_state, OT_WHOLE_LINE, NULL, true); ! if (pset.sversion 80400) ! { ! psql_error(The server (version %d.%d) does not support showing function source.\n, ! pset.sversion / 1, (pset.sversion / 100) % 100); ! status = PSQL_CMD_ERROR; ! } ! else if (!func) { psql_error(function name is required\n); status = PSQL_CMD_ERROR; -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
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 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 fastlevel integer -+---++-- public | bt_page_items | SETOF record | normal relname 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 alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
2011/11/8 Alvaro Herrera alvhe...@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 fastlevel integer -+---++-- public | bt_page_items | SETOF record | normal relname text, blkno integer, OUT itemoffset smallint, OUT ctid tid, OUT itemlen smallint, OUT nulls boolean, OUT vars boolean, 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: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
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 alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
2011/11/8 Alvaro Herrera alvhe...@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: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
On Mon, Nov 7, 2011 at 11:25 PM, Robert Haas robertmh...@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 = 8) { [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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
Josh Kupershmidt schmi...@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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
On Sun, Nov 6, 2011 at 3:29 PM, Josh Kupershmidt schmi...@gmail.com wrote: On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes lis...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
On Mon, Nov 7, 2011 at 10:04 PM, Robert Haas robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
On Mon, Nov 7, 2011 at 11:01 PM, Josh Kupershmidt schmi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
2011/11/5 Josh Kupershmidt schmi...@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: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] proposal: psql concise mode
On Sun, Nov 6, 2011 at 1:16 PM, Dickson S. Guedes lis...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 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 | plain b | 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers