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

From Josh Williams
Subject Re: Elementary dependency look-up
Date
Msg-id 1252558043.5918.213.camel@lapdragon
Whole thread Raw
In response to Re: Elementary dependency look-up  (decibel <decibel@decibel.org>)
Responses Re: Elementary dependency look-up
List pgsql-hackers
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?

- Josh Williams




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Ragged CSV import
Next
From: Jaime Casanova
Date:
Subject: new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)