Re: patch: Allow \dd to show constraint comments

On Mon, Jul 18, 2011 at 10:57 PM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
> Well, I was hoping to go by the existing psql backslash commands'
> notions about what qualifies as "system" and what doesn't; that worked
> OK for commands which supported the 'S' modifier, but not all do. For
> objects like tablespaces, where you must be a superuser to create one,
> it seems like they should all be considered is_system = true, on the
> vague premise that superuser => system. Other objects like roles are
> admittedly murkier, and I didn't find any precedent inside describe.c
> to help make such distinctions.

I think that the idea is that system objects are the ones that the
user probably doesn't care to see most of the time - i.e. the ones
that are "built in". But...

> But this is probably all a moot point, see below.

...yes.

>>> Issues still to be resolved:
>>>
>>> 1.) For now, I'm just ignoring the issue of visibility checks; I
>>> didn't see a simple way to support these checks \dd was doing:
>>>
>>>    processSQLNamePattern(pset.db, &buf, pattern, true, false,
>>>                          "n.nspname", "p.proname", NULL,
>>>                          "pg_catalog.pg_function_is_visible(p.oid)");
>>>
>>> I'm a bit leery of adding an "is_visible" column into pg_comments, but
>>> I'm not sure I have a feasible workaround if we do want to keep this
>>> visibility check. Maybe a big CASE statement for the last argument of
>>> processSQLNamePattern() would work...
>>
>> Yeah... or we could add a function pg_object_is_visible(classoid,
>> objectoid) that would dispatch to the relevant visibility testing
>> function based on object type.  Not sure if that's too much of a
>> kludge, but it wouldn't be useful only here: you could probably use it
>> in combination with pg_locks, for example.
>
> Something like that might work, though an easy escape is just leaving
> the query style of \dd as it was originally (i.e. querying the various
> catalogs directly, and not using pg_comments): discussed a bit in the
> recent pg_comments thread w/ Josh Berkus.

That's another approach. It seems a bit lame, but...

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