On Mon, Aug 15, 2011 at 2:05 PM, Darren Duncan <darren@darrenduncan.net> 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