Re: Elementary dependency look-up

From: Josh Williams <joshwilliams(at)ij(dot)net>
To: decibel <decibel(at)decibel(dot)org>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Elementary dependency look-up
Date: 2009-09-10 04:47:23
Message-ID: 1252558043.5918.213.camel@lapdragon
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2009-09-10 05:01:07 new version of PQconnectdb was:(Re: [HACKERS] Determining client_encoding from client locale)
Previous Message Tom Lane 2009-09-10 03:52:28 Re: Ragged CSV import