Thread: [feature request] split triggers into branches
Hello<br /> Have you considered to split triggers into branches?<br /> I can imagine:<br /><ul><li>triggers<ul><li>insert<ul><li>before<li>after</ul><li>update<ul><li>before<li>after</ul><li>before<ul><li>before<li>after</ul></ul></ul><p>Triggers whichare set for multiple events would appear in all particular branches.<br /> Of course it might be optional for some whodon't like it.<br /> We have a lot of triggers for single tables (50) and would be helpful to us to organize them in someway.<br /><br /> with regards<br />
On Wed, 2012-10-24 at 13:48 +0200, Michal Kozusznik wrote: > Hello > Have you considered to split triggers into branches? > I can imagine: > > * triggers > o insert > + before > + after > o update > + before > + after > o before > + before > + after > > Triggers which are set for multiple events would appear in all > particular branches. That's probably the biggest issue with your proposal. Objects shouldn't appear at different locations (yeah, we already do this with the language objects in 9.1, but I'm not sure how we should deal with that). > Of course it might be optional for some who don't like it. > > We have a lot of triggers for single tables (50) and would be helpful to > us to organize them in some way. > 50 triggers on a single table? wow, something is so wrong with your setup. I don't quite get why you would end up with so much triggers. Isn't that a big issue with performances? But I get it that with such a setup, you need a better tree. Unfortunately, your kind of setup is probably really specific, and isn't a usual one. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
a lot of bussines logic is implemented in db. splitting it into several triggers rather then using single one helps in codemanagement. just fyi. with regards MK 25. 11. 2012 v 11:31, "Guillaume Lelarge" <guillaume@lelarge.info>: > On Wed, 2012-10-24 at 13:48 +0200, Michal Kozusznik wrote: >> Hello >> Have you considered to split triggers into branches? >> I can imagine: >> >> * triggers >> o insert >> + before >> + after >> o update >> + before >> + after >> o before >> + before >> + after >> >> Triggers which are set for multiple events would appear in all >> particular branches. > > That's probably the biggest issue with your proposal. Objects shouldn't > appear at different locations (yeah, we already do this with the > language objects in 9.1, but I'm not sure how we should deal with that). > >> Of course it might be optional for some who don't like it. >> >> We have a lot of triggers for single tables (50) and would be helpful to >> us to organize them in some way. >> > > 50 triggers on a single table? wow, something is so wrong with your > setup. I don't quite get why you would end up with so much triggers. > Isn't that a big issue with performances? > > But I get it that with such a setup, you need a better tree. > Unfortunately, your kind of setup is probably really specific, and isn't > a usual one. > > > -- > Guillaume > http://blog.guillaume.lelarge.info > http://www.dalibo.com >