Re: pg_comments

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_comments
Date: 2010-09-20 11:45:28
Message-ID: AANLkTinSd1X8K2C5pRGyTpfNqM6KY3kf8Lxt0LNr_Tmc@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 20, 2010 at 1:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> In view of the foregoing problems, I'd like to propose adding a new
>> system view, tentatively called pg_comments, which lists all of the
>> comments for everything in the system in such a way that it's
>> reasonably possible to do further filtering out the output in ways
>> that you might care about; and which also gives objects the names and
>> types in a format that matches what the COMMENT command will accept as
>> input.  Patch attached.
>
> Unless you propose to break psql's hard-won backwards compatibility,
> this isn't going to accomplish anything towards making describe.c
> simpler or shorter. Also, it seems to me that what you've mostly done
> is to move complexity from describe.c (where the query can be fixed
> easily if it's found to be broken) to system_views.sql (where it cannot
> be changed without an initdb).

Those are legitimate gripes, but...

> How about improving the query in-place in describe.c instead?

...I still don't care much for this option. It doesn't do anything to
easy the difficulty of ad-hoc queries, which I think is important (and
seems likely to be even more important for security labels - because
people who use that feature at all are going to label the heck out of
everything, whereas comments are never strictly necessary), and it
isn't useful for clients other than psql. Most of this code hasn't
been touched since 2002, despite numerous, relevant changes since
then. You could take as support for your position that we need the
ability to fix future bugs without initdb, but my reading of it is
that that code is just too awful to be easily maintained and so no one
has bothered.

(It also supports my previous contention that we need a way to make
minor system catalog updates without forcing initdb, but that's a
problem for another day.)

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-09-20 12:16:42 Re: Configuring synchronous replication
Previous Message Magnus Hagander 2010-09-20 11:35:01 Re: Report: removing the inconsistencies in our CVS->git conversion