On Mon, Aug 15, 2011 at 2:05 PM, Darren Duncan <darren@xxxxxxxxxxxxxxxx> wrote: > 1. Try using multiple processes. You can have a separate process, in a > distinct transactional context, for sending the emails, and it only does so > under certain conditions, such as if it sees that a committed change has put > the processed change over 50K. The process performing the order that might > get rolled back wouldn't send the email itself, though it might explicitly > notify the other process, if the other can't tell that something happened by > itself. Its not like everything has to be a single process. This is the "obvious workaround" and not directly from within PostgreSQL. The helper process cannot be a Pg function because it can't commit it's own deletion from the queue. > > 2. The computational completeness I'm speaking of what I see as an ideal > here. Some of that computational completeness may currently be missing but > could be added later. Or it may already exist. But given the ability to do all this through helper processes and LISTEN/NOTIFY, is that even really needed? If so, why? Just because PostgreSQL may not be computationally complete in this regard, that doesn't mean that it can't be part of a computationally complete system, right? Best Wishes, Chris Travers -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
