Re: psql: bogus descriptions displayed by \d+

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Kupershmidt <schmiddy(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: psql: bogus descriptions displayed by \d+
Date: 2011-07-26 13:53:54
Message-ID: CA+TgmoYhKQp24mkzAPmRx9ctybzoFCFQ5HBUiMxvXdeF79_W+w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 25, 2011 at 10:29 PM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
> That seems like a good way to document this; patch for master updated.
> I avoided mucking with the documentation for COMMENT ON RULE and
> COMMENT ON TRIGGER this time; they both say "table" when they really
> mean "table or view", but maybe trying to differentiate between
> "table", "table_or_view", and "relation" will make things overly
> complicated.

I think this is basically the right approach but I found what you did
here a bit wordy, so I simplified it, committed it, and back-patched
to 9.0 with suitable adjustment. Hopefully I didn't simplify it into
a form you don't like.

>>> Also, a patch against master to:
>>>  * get rid of the bogus "Description" outputs for \d+ sequence_name
>>> and \d+ index_name
>>
>> This part looks OK, but instead of doing a negative test (not-index,
>> not-sequence) let's have it do a positive test, for the same types
>> comment.c allows.
>
> Right, fixed.

Committed this part to head with minor tweaks.

>>> And while I'm messing with this, some further nitpicks about psql not
>>> addressed by these patches:
>>>  * The "Storage" column for \d+ sequence_name is correct, I suppose,
>>> but repetitive
>>
>> I'm OK with removing that.
>
> Hrm, would it be better to keep that  Storage bit around in some
> non-repetitive form, maybe on its own line below the table output?

Well, I don't really see that it has any value. I'd probably just
leave it the way it is, but if we're going to change something, I
would favor removing it over relocating it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-07-26 13:55:20 Re: Another issue with invalid XML values
Previous Message Tom Lane 2011-07-26 13:52:34 Re: Another issue with invalid XML values