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 CAK3UJRHQqbVG=C9hf-fZr2p_54JH-ayJ1p-b_gfOiQx+g5CHtg@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
List pgsql-hackers
On Thu, Jul 7, 2011 at 10:00 PM, Robert Haas <robertmhaas@gmail.com> wrote:

[review of original, small patch to add another type to \dd's output]

> I am inclined to say that we should reject this patch as it stands.

That's totally OK - that original patch was of marginal use given the
larger brokenness of \dd.

> With or without pg_comments, I think we need a plan for \dd, and
> adding one object type is not a plan.  The closest thing I've seen to
> a plan is this comment from Josh:
>
> --
> ISTM that \dd is best suited as a command to show the comments for
> objects for which we don't have an individual backslash command, or
> objects for which it's not practical to show the comment in the
> backslash command.
> --
>
> If someone wants to implement that, I'm OK with it, though I think we
> should also consider the alternative of abolishing \dd and just always
> display the comments via the per-object type commands (e.g. \d+ would
> display the table, constraint, trigger, and rule comments).

And I'm quite happy you said that: I'm just about to post part 1 of a
patch to start fixing up the individual backslash commands which
clearly should be showing comments, but aren't. I'm thinking that
clarifying which backslash commands should show object comments, and
which types must be left for \dd to clean up can be handled separately
from pg_comments. And my preference is to whittle down \dd to as
little as necessary (if it could be gotten rid of entirely, even
better, but I doubt that's going to fly).

> I don't
> want to, as Josh says, let the perfect be the enemy of the good, but
> if we change this as proposed we're just going to end up changing it
> again.  That's going to be more work than just doing it once, and if
> it happens over the course of multiple releases, then it creates more
> annoyance for our users, too.  I don't really think this is such a
> large project that we can't get it right in one try.

Fair enough. If the pg_comments patch does go down in flames, I can
circle back and patch up the rest of the holes in \dd.

Josh


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.
Next
From: Kohei KaiGai
Date:
Subject: Re: [v9.2] DROP Reworks Part.1 - Consolidate routines to handle DropStmt