Re: [PATCHES] YADP - Yet another Dependency Patch

From: "Rod Taylor" <rbt(at)zort(dot)ca>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Hackers List" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] YADP - Yet another Dependency Patch
Date: 2002-04-18 03:21:44
Message-ID: 024701c1e688$2d79c3e0$8001a8c0@jester
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-04-18 03:24:28 Re: BETWEEN SYMMETRIC/ASYMMETRIC
Previous Message Christopher Kings-Lynne 2002-04-18 03:20:39 Re: BETWEEN SYMMETRIC/ASYMMETRIC

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-04-18 03:29:28 Re: [PATCHES] A bug in gist code with fetch/move
Previous Message Peter Eisentraut 2002-04-18 03:16:01 Re: [HACKERS] build of 7.2.1 on SCO Openserver and Unixware