One issue to consider in this is scheduling database load. In the current dbmail-util setup, for better or worse, deleting a user or mailbox doesn't take the heavier hit of removing all their mail. I can come up with some nice worst cases for either method (ie. deleting physical messages all at one shot in off-hours or spreading the load throughout the day, whenever a user is deleted) - I don't know what would be better in practice. I like the flexibility, but it may not be worth the confusion, created by making either work - an optional trigger to load if you want that method, otherwise dbmail-util cleans it up.
On Sat, 2007-07-07 at 22:51 +0200, Paul Stevens wrote: > Try this (untested): > > CREATE PROCEDURAL LANGUAGE plpgsql; > > create function physmessage_gc() returns "trigger" > as $$ > begin > delete from dbmail_physmessage where OLD.physmessage_id > not in (select physmessage_id from dbmail_messages); > return OLD; > end; > $$ > language plpgsql; > > create trigger message_delete > after delete on dbmail_messages > for each row > execute procedure physmessage_gc(); > > I'll be adding more stuff like that to the trunk code as we move > toward > 2.3.0. With mysql-5.0/postgresql-8.x/sqlite-3 we can start using rich > triggers and procedures to take care of all the basic stuff that is > still done with dbmail-util. -- Jesse Norell Kentec Communications, Inc. [EMAIL PROTECTED] _______________________________________________ Dbmail-dev mailing list Dbmail-dev@dbmail.org http://twister.fastxs.net/mailman/listinfo/dbmail-dev
