Re: UNLOGGED tables in psql \d

From: Cédric Villemain <cedric(dot)villemain(dot)debian(at)gmail(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: UNLOGGED tables in psql \d
Date: 2011-02-22 13:03:35
Message-ID: AANLkTi=_b1yw5qBnYTiWKGONNXYVumOrO1FerZ3cXAec@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/2/22 Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>:
> On Tue, Feb 22, 2011 at 18:11, Cédric Villemain
> <cedric(dot)villemain(dot)debian(at)gmail(dot)com> wrote:
>> 2011/2/22 Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>:
>>> psql \d(+) doesn't show any information about UNLOGGED and TEMP attributes
>>> for the table. So, we cannot know the table is unlogged or not unless
>>> we directly select from pg_class.relpersistence.  Is this a TODO item?
>>
>> I believe it is in the "title" of the table presented by \d (Table,
>> Unlogged table, Temp table)
>
> Ah, I see. Thank you.  They are shown as "Unlogged Table" and
> "Unlogged Index".
>
> - We don't have "Temp" for temp tables. Should we have?

Hum, First, I would say yes to be more consistent with the unlogged
case, but 2nd we must refrain from outputting too much information
where it is not relevant.

The fact that you didn''t saw it might be enough to reconsider the way
we display the unlogged state (and temp state) of a relation.

Maybe some a "Durability: normal, temp, unlogged" line at bottom of
the \d output ?

> - The head characters of the second words would be small letters.
>  We describe other objects as "Composite type", "Foreign table", or so.
>
> --
> Itagaki Takahiro
>

--
Cédric Villemain               2ndQuadrant
http://2ndQuadrant.fr/     PostgreSQL : Expertise, Formation et Support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-02-22 13:04:08 Re: Sync Rep v17
Previous Message Heikki Linnakangas 2011-02-22 13:01:45 Re: Snapshot synchronization, again...