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
|
Список | 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 по дате отправления: