On Thu, Sep 10, 2009 at 10:23 AM, Robert Haas <robertmh...@gmail.com> wrote: > 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.
I'm not sure there's any point in reviewing this patch in its present form. Barring objections (or a new version), I think we should mark this Returned with Feedback. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
