On Mon, Jul 18, 2011 at 10:57 PM, Josh Kupershmidt <schmi...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
