From: | Mike Mascari <mascarm(at)mascari(dot)com> |
---|---|
To: | Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)cz> |
Cc: | "Ross J(dot) Reedstrom" <reedstrm(at)wallace(dot)ece(dot)rice(dot)edu>, pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>, Bryan White <bryan(at)arcamax(dot)com> |
Subject: | Re: [HACKERS] Re: [INTERFACES] The persistance of C functions |
Date: | 2000-02-11 07:11:25 |
Message-ID: | 38A3B61D.73F45891@mascari.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-interfaces |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2000-02-11 07:16:21 | Re: [HACKERS] Almost there on column aliases |
Previous Message | Chris Bitmead | 2000-02-11 06:57:59 | Re: [HACKERS] Solution for LIMIT cost estimation |
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Verstak | 2000-02-11 07:12:06 | Re: [INTERFACES] JDBC primary keys |
Previous Message | S.F. Lee | 2000-02-11 06:58:38 | ecpg core dump |