Re: Triggers don't activate when dropping table - Mailing list pgsql-general
From | cheng shan |
---|---|
Subject | Re: Triggers don't activate when dropping table |
Date | |
Msg-id | 20041207064137.80142.qmail@web15502.mail.cnb.yahoo.com Whole thread Raw |
In response to | Triggers don't activate when dropping table (cheng shan <postgresql_general@yahoo.com.cn>) |
Responses |
Re: Triggers don't activate when dropping table
Re: Triggers don't activate when dropping table |
List | pgsql-general |
Note: forwarded message attached.
Do You Yahoo!?
注册世界一流品质的雅虎免费电邮
The reason I drop the table directly is that:
I am developing a graphical information system. There are many tables inherit from object in the system, such as "map", "line", "rect", "circle", etc. In most time, I use tables inherit from "object" instead of table "object".
I group the "objects" in such manners as "map" contains the drawable objects, such as "rect", "circle". And some "object" maybe consists of other "objects", such as a "rect" is assembled by four "line". Besides there are also many relationships between "objects".
Our principle is to construct a model that reflects the association among objects. We use table "relationship" and tables that inherits from it to record the OID of objects that participate this "relationship". And also, every "object" has a field to record the "relationship"s it participates in. To maintain the above constraint automatically, I define many triggers on every "object" table and every "relationship" table.
To make the system extensible, we provides interface make_object_type( ) to permit the user to create the "object type" inherits from "object". And if the user think the existing table is unappropriate, he may drop it using function destroy_object_type( ) if he has sufficient priviledge.
In the first version, the function destroy_object_type( ) just drop the table only. But when I find the triggers havn't been actived yet, I add the delete setense. This time it becomes even worse, the system throws error message.ERROR: could not open relation with OID 1390714.
To avoid the fatal error, I have no choice but to rollback the function to the original version.
I have written a simplified test cast to verify the system, but it performs as I expected and it's wrong.
Could you help me?
Thanks!
Michael Fuhr <mike@fuhr.org> wrote:
On Tue, Dec 07, 2004 at 11:44:58AM +0800, cheng shan wrote:
> I have one table named "object" and i many tables that are related
> to the table "object". When a record in "object" is deleted, the
> relative records in other tables should also be erased. To implement
> the above goal, i define many triggers on table "object" to make
> operations automatically.
>
> But i find that the triggers don't activate when i dropping the
> table "object". So there is many garbage information left in the
> system which makes the system unstable.
If you want to fire the triggers then delete all records from the
table before dropping it. But why are you dropping the table?
--
Michael Fuhr
http://www.fuhr.org/~mfuhr/
---------------------------(end of broadcast)---------------------------
TIP 9: the p lanner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Do You Yahoo!?
注册世界一流品质的雅虎免费电邮
pgsql-general by date: