> 2) Use triggers instead of rules wherever possible
> 3) From the docs: "If more than one trigger is defined for the same
> event on the same relation, the triggers will be fired in alphabetical
> order by trigger name. In the case of before triggers, the
> possibly-modified row returned by each trigger becomes the input to the
> next trigger. If any before trigger returns NULL, the operation is
> abandoned for that row and subsequent triggers are not fired."
> - Josh / eggyknap
Steve,
What you are doing can be implemented with rules or triggers. I wouldn't agree with Josh that in all cases a trigger is better than a rule. It depends on your pattern of inserts and if you are optimizing for speed or manageability or what.
Either way, you will want to put check constraints in each of your tables and have constraint_exclusion = on for your db so you can take advantage of constraint exclusion. And even ask the very fundamental question of if you really have enough data that it makes the most sense to partition right now.
Anyrate Robert Treat's slide is a good primer of how to use both approaches and the pros and cons of each.
http://www.slideshare.net/xzilla/postgresql-partitioning-pgcon-2007-presentation
Just my 2 cents,
Regina
The substance of this message, including any attachments, may be confidential, legally privileged and/or exempt from disclosure pursuant to Massachusetts law. It is intended solely for the addressee. If you received this in error, please contact the sender and delete the material from any computer.
Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper.