Re: SHOW ALL output too wide

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SHOW ALL output too wide
Date: 2005-11-26 15:08:40
Message-ID: 200511261508.jAQF8eL11174@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dennis Bjorklund wrote:
> On Fri, 25 Nov 2005, Bruce Momjian wrote:
>
> > > > Is there any use for SHOW except in interactive psql sessions?
> >
> > There certainly is. Imagine querying for timezone. Also remember that
> > pgadmin is a client application that is _not_ psql.
>
> I should have written SHOW ALL, that's the command output that is too wide
> to fit in a normal terminal window. Do pgadmin use SHOW ALL?

No idea, but it doesn't matter. We have no way of knowing what
interfaces use which commands.

> I would expect pgadmin to query pg_settings so that it get all info about
> the variable that is stored and show it in the gui in some way. But I
> don't use pgadmin so I don't know how it show the list of server
> variables.

The project goal is not to make everyone happy with every behavior, but
rather choose defaults that are acceptable to the majority of people.
If people want to modify their local copy of PostgreSQL, they are
welcome to do so.

> SHOW ALL really is an interactive command line interface command that is
> implemented by the server.

Well, many have complained that the psql backslash commands should
rather be in the backend, and the information schema has added that.

> > > Nothing that can't be done by querying pg_settings.
> >
> > True, so we have pg_settings and SHOW. I see no reason for a third,
> > \show.
>
> The same can be said about all slash-commands in psql.

Right, see above. Moving more into the client seems like the wrong
direction.

> By the way, we have yet another way. We have the functions that fetch
> server variable settings, like pg_show_all_settings().

OK.

> Is your suggestion that we keep SHOW ALL as is? Or is that we extend it to
> something like SHOW ALL NO DESC?

NO DESC is just too ugly, especially since DESC is short for DESCENDING
in the standard. I originally suggested VERBOSE, but no one replied,
and I thought it might be overkill. Using that system, SHOW and SHOW
ALL would not show descriptions, but SHOW VERBOSE [ALL] would.

> If we keep it as is then I would like to ask who is the target user it's
> designed for? It's probably not for psql users since the output isn't
> readable by anyone but those that have terminal windows > 165 characters
> wide. It can't be for computer clients since those don't need the
> description column. So who is it designed for?

See the discussion or really solo request by me for more feedback when
this change was made for 8.1:

http://archives.postgresql.org/pgsql-patches/2005-06/msg00295.php

Where were you when I asked? Didn't you notice it in the release notes
that have been online for months?

* Make "SHOW ALL" include variable descriptions (Matthias Schmidt)

It is unlikely this will be changed in any 8.1.X release. If you want it
modified for 8.2, we will need to see more than one person complaining
about it, because until now no one has complained about the documented
8.1 change. If you can find a sufficient number of people who like the
VERBOSE idea, we can make this modification for 8.2. In the mean time,
you can use a psql \set macro to run a query that pulls the fields from
pg_settings.

\set show 'select name, setting from pg_settings;'

and call it with :show. Same number of characters as '\show'. :-)

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-11-26 15:37:46 Re: PL/php in pg_pltemplate
Previous Message Simon Riggs 2005-11-26 12:39:21 Re: gprof SELECT COUNT(*) results