On Thu, Sep 10, 2009 at 12:47 AM, Josh Williams <joshwilli...@ij.net> wrote: > On Wed, 2009-09-09 at 11:30 -0500, decibel wrote: >> On Sep 9, 2009, at 8:05 AM, Peter Eisentraut wrote: >> > How is this better than just reading the information directly from >> > pg_depend? >> >> pg_depend is very difficult to use. You have to really, really know >> the catalogs to be able to figure it out. Part of the problem is >> (afaik) there's nothing that documents every kind of record/ >> dependency you might find in there. > > Exactly - these functions were designed around making that easier for > the end user. The less poking around in system catalogs a user has to > do the better. > > Yeah, the documentation about what can be found in pg_depend is > scattered at best, though then again there doesn't seem to be a whole > lot in there that's of much interest to end users... Actually, apart > from pg_get_serial_sequence() do we have anything else that utilizes > dependency data to show the user information? > >> What might be more useful is a view that takes the guesswork out of >> using pg_depend. Namely, convert (ref)classid into a catalog table >> name (or better yet, what type of object it is), (ref)objid into an >> actual object name, and (ref)objsubid into a real name. > > Makes sense, would be much more future-proof. It shouldn't be difficult > to put in some intelligence to figure out the type of object, such as > looking at relkind if (ref)classid = pg_class. > > It might be a little difficult to maintain, depending on what else finds > its way into the system catalogs later (but then, probably not much more > so than INFORMATION SCHEMA is.) Would that be preferable, over a couple > additional functions?
+1. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers