From: Mike Mascari <mascarm@mascari.com>
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
Cc: Ross J. Reedstrom <reedstrm@wallace.ece.rice.edu>
Cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Cc: Bryan White <bryan@arcamax.com>
Subject: Re: [HACKERS] Re: [INTERFACES] The persistance of C functions
Date: Fri, 11 Feb 2000 02:11:25 -0500
Message-ID: <38A3B61D.73F45891@mascari.com> (raw)
References: <Pine.LNX.3.96.1000211112520.23828B-100000@ara.zf.jcu.cz>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: mascarm@mascari.com, zakkr@zf.jcu.cz, reedstrm@wallace.ece.rice.edu, pgsql-hackers@postgreSQL.org, bryan@arcamax.com
Subject: Re: [HACKERS] Re: [INTERFACES] The persistance of C functions
In-Reply-To: <38A3B61D.73F45891@mascari.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox