Re: psql \d commands and information_schema

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql \d commands and information_schema
Date: 2009-04-05 23:52:11
Message-ID: 4719.1238975531@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Martin Pihlak <martin(dot)pihlak(at)gmail(dot)com> writes:
> 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.

Well, if they're all in your search_path then plain old \df will do
fine. If they're not in your search path then I think it gets pretty
questionable whether they're "user defined" in a real sense. It seems
more likely that you've got a pile of modules loaded, and which of those
modules is "user defined" for your immediate purposes is something that
psql can't hope to intuit.

In short I'm still not convinced that there's much use-case for a
simple "U" switch.

> 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.*, ...'

Possibly something like this could be useful. But I'd like to see it
designed in conjunction with the "real module facility" that we keep
hoping for, because I think a situation with a number of modules loaded
is going to be exactly where you want some flexible filtering.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-04-05 23:56:52 Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT
Previous Message Tom Lane 2009-04-05 23:25:07 Re: Python 3.0 does not work with PL/Python