Sender: mascarm@corvette.mascari.com
Message-ID: <38A3B61D.73F45891@mascari.com>
Date: Fri, 11 Feb 2000 02:11:25 -0500
From: Mike Mascari <mascarm@mascari.com>
Organization: Mascari Development Inc
MIME-Version: 1.0
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
CC: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
	pgsql-hackers <pgsql-hackers@postgreSQL.org>,
	Bryan White <bryan@arcamax.com>
Subject: Re: [HACKERS] Re: [INTERFACES] The persistance of C functions
References: <Pine.LNX.3.96.1000211112520.23828B-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Karel Zak - Zakkr wrote:

> > Not _totally_ safe: if you've got anything that refers to that function,
> > like a user defined type definition, drop/(re)create will change the
> > function's oid in the pg_proc table, causing errors when the old
> > function is looked up. Hmm, an ALTER FUNCTION command might be nice...
>
> ... and/or check dependencies on the function's oid if the function is DROP,
> (via FOREIGN KEYs ?). IMHO it is good item to TODO if really nothing check
> it.  (...resending to hackers)
>
>                                                         Karel

Yes. I think it would be an interesting discussion to see whether or not it would
be a good idea to integrate referential integrity with respect to the system
cataloge. The result *could* be backend code which is far easier to maintain, and
(with updateable oids), support for ALTER/DROP code which yields sane results. For
example, with the little COMMENT code, I had to find the backend code responsible
for dropping each of the associated object types - relations, aggregates, types,
functions, etc. in order to also drop the associated COMMENT. *AND *I also had to
find those areas where an object might be implicitly dropped by dropping another
object by calling a different routine -- for example, DROP TRIGGER calls a
different routine (DropTrigger) than what is called by the DROP TABLE code to drop
all triggers associated with it (RelationRemoveTriggers). With RI, a cascading
delete from pg_class could automatically drop the associated indexes, triggers,
comments, etc. And perhaps another trigger on pg_class should be used to remove the
actual relation file itself. Then one would only need to determine whether the DROP
should be allowed (if, for instance, it is a base class of an inheritence
hierarchy) or it should be rejected by the RI code. Likewise, the ALTER code could
perform a cascading update of oid (if necessary), to aide pg_dump when dumping
objects in oid order (TODO) to reduce the possibility of breaking a dependency...

Just some thoughts,

Mike Mascari