> 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.
