a lot of bussines logic is implemented in db. splitting it into several triggers rather then using single one helps in code management. just fyi.
with regards MK 25. 11. 2012 v 11:31, "Guillaume Lelarge" <guilla...@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 > -- Sent via pgadmin-support mailing list (pgadmin-support@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-support
