Re: Elementary dependency look-up - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Elementary dependency look-up
Date
Msg-id 603c8f070909100723j7a2cbcbyecb3d392d559355b@mail.gmail.com
Whole thread Raw
In response to Re: Elementary dependency look-up  (Josh Williams <joshwilliams@ij.net>)
Responses Re: Elementary dependency look-up
List pgsql-hackers
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.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Ragged CSV import
Next
From: Emmanuel Cecchet
Date:
Subject: COPY enhancements