Re: psql \d commands and information_schema

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: psql \d commands and information_schema
Дата
Msg-id 4719.1238975531@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: psql \d commands and information_schema  (Martin Pihlak <martin.pihlak@gmail.com>)
Ответы Re: psql \d commands and information_schema  (Martin Pihlak <martin.pihlak@gmail.com>)
Список pgsql-hackers
Martin Pihlak <martin.pihlak@gmail.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Python 3.0 does not work with PL/Python
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE ... ALTER COLUMN ... SET DISTINCT