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

Reply via email to