From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
Cc: | Thom Brown <thom(at)linux(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_comments (was: Allow \dd to show constraint comments) |
Date: | 2011-10-17 02:04:22 |
Message-ID: | CA+TgmoYD5hXv=dfHfqAJA4dtL1kFRcK5VEM=EdgL6qu-F10C3Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Oct 14, 2011 at 11:12 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Oct 12, 2011 at 10:20 PM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
>>> On the third hand, Josh's previous batch of changes to clean up
>>> psql's behavior in this area are clearly a huge improvement: you can
>>> now display the comment for nearly anything by running the appropriate
>>> \d<foo> command for whatever the object type is. So ... is this still
>>> a good idea, or should we just forget about it?
>>
>> I think this question is a part of a broader concern, namely do we
>> want to create and support system views for easier access to
>> information which is already available in different ways through psql
>> commands, or by manually digging around in the catalogs? I believe
>> there are at least several examples of existing views we maintain
>> which are very similar to pg_comments: pg_seclabel seems quite
>> similar, for instance.
>
> That's one's a direct analogue, but I don't want to overbroaden the
> issue. I guess it just seems to me that if no one's going to champion
> adding this, maybe we shouldn't.
Hearing no cries of "oh, yes, please", I'm marking this Returned with
Feedback for now. We can always revisit it if we hear that more
people want it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2011-10-17 06:00:19 | Re: Large C files |
Previous Message | Robert Haas | 2011-10-17 01:21:54 | Re: proposal: set GUC variables for single query |