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
>
