Re: psql \d commands and information_schema

Tom Lane wrote:
> I don't find this to be a pressing problem. If the user has lots of
> schemas, they probably have lots of objects too, and are unlikely to
> need such a thing.

Current behaviour makes it impossible to get a quick overview of all the
user defined objects. And it doesn't really matter what the number of
schemas is -- it gets messy for even small number of schemas and objects.
Lets assume 2 user tables in schemas "public" and "foo".

\dt *.* will give:
List of relations
Schema | Name | Type | Owner
--------------------+-------------------------+-------+---------
foo | t2 | table | martinp
information_schema | sql_features | table | martinp
...
pg_catalog | pg_aggregate | table | martinp
...
public | t1 | table | martinp
(51 rows)

This is a lot of irrelevant stuff the user has to filter out. It is
much worse with functions -- \df *.* results in 1900+ functions that
I usually don't want to see. The alternative is to perform a \dn first
and then loop through that (this is the annoyance the U switch would
remove).

> search_path enters into it too; a simple U switch isn't going to provide
> a full answer.
>

For our needs I wouldn't really consider using search_path for anything
but temporary hacks. However, a psql variable that specifies a list of
name patterns to be excluded from describe, could be useful. Something
along the lines of:

\set DESCRIBE_EXCLUDE_PATTERNS 'pg_catalog.*, information_schema.*, ...'

This could be then customized to each site's needs -- add pgq, slony,
etc. and put to .psqlrc. It is questionable whether the filter should be
applied to default \dX (override with S to describe all). Maybe it'd be
better to introduce an extra switch that applies the filters.

I just noticed that something similar was already suggested by Euler in
http://archives.postgresql.org/message-id/49CDB4E0.8030603@timbira.com

regards,
Martin