On Thu, Sep 10, 2009 at 10:23 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Sep 10, 2009 at 12:47 AM, Josh Williams <joshwilliams@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