Thread: Re: [PATCHES] YADP - Yet another Dependency Patch

> 3. Isn't there a better way to find the initial dependencies?  That
> SELECT is truly ugly, and more to the point is highly likely to
break
> anytime someone rearranges the catalogs.  I'd like to see it
generated
> automatically (maybe using a tool like findoidjoins); or perhaps we
> could do the discovery of the columns to look at on-the-fly.

I'm having a really hard time coming up with a good method for this.

The key problems with doing what findoidjoins does is recording things
like indexes, complex types, etc. as items that should be implicitly
dropped when the table is dropped.   Also, in the case of indicies the
work required to 'discover' 2 value foreign keys against pg_attribute
(attnum and attrelid) would be a royal pain in the ass -- especially
when it's in the form of a vector (ugh).  There are enough of those to
warrent something other than hardcoding the relations in c code.

It might be possible to create foreign keys for the system tables and
use those to discover the associations.  Any foreign key in pg_catalog
made up of an object address (table, oid column) or (table, oid
column, int column) could potentially have each foreign key tuple set
(join tables by key) recorded as a dependency.

So...  Any thoughts to adding a no-op foreign key reference?  A key
thats used for style purposes only.

"Rod Taylor" <rbt@zort.ca> writes:
>> 3. Isn't there a better way to find the initial dependencies?  That
>> SELECT is truly ugly, and more to the point is highly likely to
>> break anytime someone rearranges the catalogs.

> I'm having a really hard time coming up with a good method for this.

Well, do we actually need an *accurate* representation of the
dependencies?  You seemed to like my idea of pinning essential stuff,
and in reality all of the initial catalog structures ought to be pinned.
Maybe it would be sufficient to just make "pinned" entries for
everything that appears in the initial catalogs.  Someone who's really
intent on manually deleting, say, the "box" datatype could be expected
to be bright enough to figure out how to remove the pg_depends entry
that's preventing him from doing so.

(There are a very small number of things that are specifically intended
to be droppable, like the "public" namespace, but seems like excluding
that short list from the pg_depends entries would be more maintainable
than the approach you've got now.)
        regards, tom lane

Thats what I was going to propose if no-one could figure out a way of
automatically gathering system table dependencies.

It would be nice (for a minimallist db) to be able to drop a bunch of
stuff, but a number of other things would need to be done as well
(full system compression for example).

--
Rod
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Rod Taylor" <rbt@zort.ca>
Cc: "Hackers List" <pgsql-hackers@postgresql.org>
Sent: Thursday, April 18, 2002 1:24 AM
Subject: Re: [HACKERS] [PATCHES] YADP - Yet another Dependency Patch


> "Rod Taylor" <rbt@zort.ca> writes:
> >> 3. Isn't there a better way to find the initial dependencies?
That
> >> SELECT is truly ugly, and more to the point is highly likely to
> >> break anytime someone rearranges the catalogs.
>
> > I'm having a really hard time coming up with a good method for
this.
>
> Well, do we actually need an *accurate* representation of the
> dependencies?  You seemed to like my idea of pinning essential
stuff,
> and in reality all of the initial catalog structures ought to be
pinned.
> Maybe it would be sufficient to just make "pinned" entries for
> everything that appears in the initial catalogs.  Someone who's
really
> intent on manually deleting, say, the "box" datatype could be
expected
> to be bright enough to figure out how to remove the pg_depends entry
> that's preventing him from doing so.
>
> (There are a very small number of things that are specifically
intended
> to be droppable, like the "public" namespace, but seems like
excluding
> that short list from the pg_depends entries would be more
maintainable
> than the approach you've got now.)
>
> regards, tom lane
>