psql's \dn versus temp schemas

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: psql's \dn versus temp schemas
Date: 2010-09-18 19:11:36
Message-ID: 16710.1284837096@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 | postgres
pg_catalog | postgres
pg_temp_2 | postgres
pg_toast | postgres
pg_toast_temp_1 | postgres
pg_toast_temp_2 | postgres
pg_toast_temp_3 | postgres
pg_toast_temp_4 | postgres
public | postgres
testxmlschema | 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-09-18 19:38:45 Re: Serializable Snapshot Isolation
Previous Message Kevin Grittner 2010-09-18 18:52:29 Re: Serializable Snapshot Isolation