Skip site navigation (1) Skip section navigation (2)

Re: psql \l to accept patterns

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: psql \l to accept patterns
Date: 2013-01-07 21:16:38
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Jan 7, 2013 at 7:14 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> Here is a patch for psql's \l command to accept patterns, like \d
>> commands do.  While at it, I also added an "S" option to show system
>> objects and removed system objects from the default display.  This might
>> be a bit controversial, but it's how it was decided some time ago that
>> the \d commands should act.

> -1 from me on that last bit.  I don't think that you can really
> compare the postgres or template1 database to, say, the pg_toast
> schema.  There's no real reason for people to ever care about objects
> in the pg_toast schema, but the same cannot be said about template1,
> which it's often necessary to connect to when running many of the
> commands (vacuumdb -a, etc.) we ship with our distribution.  I think
> this will just be confusing to users without any real upside.

Suppressing the postgres DB is even worse.

I think that it might be sensible to have an "S" option and define
"system" DBs as those without datallowconn, which ordinarily would only
hide template0.  But I can't get real excited about that.  People do
need to know about the existence of template0 (for use in
CREATE DATABASE ... TEMPLATE ...), which is not so true of, say,
pg_temp_NNN schemas.  The "it reduces clutter" argument also seems
pretty weak if we're only hiding one database, or even three of them.

On the whole I lean towards not adding this notion.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2013-01-07 21:19:36
Subject: Re: Improve compression speeds in pg_lzcompress.c
Previous:From: Kohei KaiGaiDate: 2013-01-07 21:14:32
Subject: Re: ALTER command reworks

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group