Re: patch: Allow \dd to show constraint comments - Mailing list pgsql-hackers

From Josh Kupershmidt
Subject Re: patch: Allow \dd to show constraint comments
Date
Msg-id BANLkTi=8Nfnw0sYQG=-tKthRNpLzhGceUw@mail.gmail.com
Whole thread Raw
In response to Re: patch: Allow \dd to show constraint comments  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: patch: Allow \dd to show constraint comments  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Sun, May 22, 2011 at 11:33 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, May 19, 2011 at 10:36 PM, Josh Kupershmidt <schmiddy@gmail.com> wrote:
>> Precisely, and I think there's a solid argument for putting
>> constraints into bucket 1 above, as this patch does, since there's no
>> good room to display constraint comments inside \d+, and there's no
>> backslash command specifically for constraints.
>>
>> I was kind of hoping to avoid dealing with this can of worms with this
>> simple patch, which by itself seems uncontroversial. If there's
>> consensus that \dd and the other backslash commands need further
>> reworking, I can probably devote a little more time to this. But let's
>> not have the perfect be the enemy of the good.
>
> Frankly, I think \dd is a horrid kludge which has about as much chance
> of being useful as a fireproof candle.  I don't really object to the
> patch at hand: it'll probably solve your problem, or you wouldn't have
> bothered writing the patch.  At the same time, I can't shake the
> feeling that it solves your problem mostly by accident.  Clearly, you
> have more than no comments on constraints (or you wouldn't care) and
> you must also have few enough constraints on the types of objects
> which \dd has randomly decided to care to make it feasible to look at
> one big list and pick out the information you're interested in.

Well actually, I got into messing with this solely from the Todo list.
Which, of course, neglected to mention the thread about pg_comments,
or the other objects missing from \dd.

> It's
> hard to work up a lot of enthusiasm for that being a common situation,
> even though, as you say, this certainly isn't making anything any
> worse.
>
> I continue to think that the right fix for this problem is the one I
> proposed here:
>
> http://archives.postgresql.org/pgsql-hackers/2010-09/msg01080.php

Yeah, I'm on board with you about the utility of a pg_comments system
view. I don't buy Tom's quick dismissal of the idea; to recap, he
complained that:

| 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.

Well, the real problem here, as I see it, is:a.) We are schizophrenic about which comments are displayed by \dd
and which are displayed by other backslash commands. And some comments
aren't yet displayed anywhere, making the COMMENT ON syntax for them
basically useless (what good is a comment no one can see without
digging around in the system catalogs by hand..)b.) One can comment on something like 32 different types of objects;
so if we actually fixed all the holes in \dd, it could be a real
nuisance trying to grep through its output to find the comments for
the objects you're actually interested in. Which leads to the
desirability of having a system view you could construct ad-hoc
queries against.

If we were to introduce pg_comments in 9.2, I would ideally want us to
fix up \dd  to work better against older server versions (i.e. the
original patch, plus some more work) as well, so the complaint about
backwards compatibility shouldn't be a concern.

And Tom complained:

| 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).

Well, the complexity in describe.c doesn't bother me too badly, as
long as commands do what they're supposed to. The real reason to move
the logic into a system view, IMO, would be for ad-hoc queries, with
utility to tools other than psql a secondary win.

And if we followed Tom's logic about system views being bad ipso
facto, we should want to rip out all non-critical system views (no, I
don't want this). I would agree that if we want to create pg_comments
we should make sure that, at the least, it displays comments for all
object types from the get-go, given Tom's valid warning about the
impossibility of upgrading a system view within a minor version.

Your pg_comments.patch doesn't apply to git head anymore -- would you
be interested in resurrecting this code for 9.2, assuming we can get
support for this idea?

Josh


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Reducing overhead of frequent table locks
Next
From: Greg Smith
Date:
Subject: 9.2 schedule