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