From: | "Manera, Villiam" <vmanera(at)manord(dot)com> |
---|---|
To: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org> |
Cc: | <pgsql-hackers(at)postgresql(dot)org>, "postgresql-it" <postgresql-it(at)lists(dot)psql(dot)it> |
Subject: | R: R: [postgresql-it] no cascade triggers? |
Date: | 2007-07-02 09:50:28 |
Message-ID: | BC53C974C3B9E542BC0A9BD4C5B1168A0276D3A2@NEWMAIL.manord.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> To be honest..No trigger necessary...
I have 1300 triggers and 345 functions (53500 lines of code), most of
them written 15 years ago for ALLBASE/SQL (the old Hewlett Packard
relational dbms) and converted to pl/pgsql last year.
I admit that some of them may look eccentric, but some of them are very
old...
Having short deadlines for the database migration we didn't have the
time to study, understand and rewrite each one so we decided to just
convert them since the language is very similar..
Ok, now we have more time, our boss is very happy that postgres
performance is 15-20 times better than ALLBASE J so now we could afford
the rewriting of functions and triggers :( .
If there's no other trick or suggestion, I think I'll build my own home
made "pg_trigger" relation containing the reference to all my
triggers/functions and a flag for each of them that tells me if it's
enabled or not.
It could be useful IMHO to at least specify in the documentation the
exact behaviour of Postgres ALTER TABLE ENABLE/DISABLE TRIGGER when
applied from a trigger on the same table the trigger belong to.
Here a more complex example:
relation A : list of components of the fashion model (without colours)
relation B : list of components of the fashion model for colours and
sizes
1) One model inserted on relation A :
* Fires then function 1 that inserts colours on relation B
* Every record inserted on B fires function 2
2) Function 2 :
* Does some checks, calculations and finally updates the record
just inserted with the right amount for every size of the model
3) ... does other non interesting things for the problem.
Function 2 disables trigger before updating the relation B because
there is another trigger that fires on the update of the q.ty of the
size in relation B.
Function 2 is invoked not only by a wrapper trigger on relation B, but
sometimes directly by user programs.
Sorry for the disturb, this is the last one.
Villiam
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2007-07-02 10:55:20 | Re: GiST consistent function, expected arguments; multi-dimensional indexes |
Previous Message | Hannu Krosing | 2007-07-02 08:52:57 | Re: todo: Hash index creation |