Chris Travers wrote:
> On Mon, Aug 15, 2011 at 1:44 PM, Darren Duncan <darren@darrenduncan.net> wrote:
>> I believe that it is ideal for Postgres to be computationally complete in
>> that one *could* use it to implement a complete application. That isn't to
>> say one should do this as a matter of course, good to use appropriate tools
>> for a job, but that it should at least be possible if one wanted to. --
>
> I think the limit is actually transactional control.
>
> So, suppose I manage inventory....
>
> I want an email to go out to the ordering manager when the quantity I
> have of an item drops below the re-order point. I also want this
> email NOT to go out if the transaction rolls back. (Wait, the order
> of 50000 widgets I just processed rolled back because it isn't to a
> valid customer! We normally only sell 50000 per year anyway. No need
> for the email.)
>
> 1) I don't see how this is possible directly from within PostgreSQL
> 2) Given the obvious ways around this, I don't see why this is
> desirable to add to PostgreSQL.....
I have 2 answers to this:
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.
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.
-- Darren Duncan
