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.8030...@timbira.com
regards,
Martin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
