psql's \dn versus temp schemas

Поиск
Список
Период
Сортировка
От Tom Lane
Тема psql's \dn versus temp schemas
Дата
Msg-id 16710.1284837096@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: psql's \dn versus temp schemas  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
psql's \dn command hides pg_temp_nn schemas, except for the current
backend's own temp schema (if any).  However, when we added separate
pg_toast_temp_nn schemas for TOAST tables, \dn wasn't taught about that,
leading to such odd-looking output as this:

regression=# \dn       List of schemas       Name        |  Owner   
--------------------+----------information_schema | postgrespg_catalog         | postgrespg_temp_2          |
postgrespg_toast          | postgrespg_toast_temp_1    | postgrespg_toast_temp_2    | postgrespg_toast_temp_3    |
postgrespg_toast_temp_4   | postgrespublic             | postgrestestxmlschema      | postgres
 
(10 rows)

regression=# 

This is at least inconsistent and at worst wildly misleading.  ISTM
we ought to adopt some combination of the following ideas:

1. Don't show pg_toast_temp_nn schemas ever.  Maybe hide pg_toast too
for consistency.

2. Show only the current backend's pg_toast_temp_nn schema.  (Note:
I don't see any very easy way to implement that :-(; psql doesn't
have easy access to the backend's slot number.  The way that it
identifies the pg_temp_nn schema is a hack that won't scale.)

3. Don't show either pg_temp_nn or pg_toast_temp_nn schemas, not even
for the current backend.

4. Forget about hiding these schemas at all.

With any of 1-3 we could also consider adding a rule that \dn+
doesn't hide them.

Thoughts?
        regards, tom lane


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

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: Re: Serializable Snapshot Isolation
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Serializable Snapshot Isolation