On Mon, Aug 15, 2011 at 3:50 PM, Chris Travers <chris.travers@gmail.com> 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.
100% agree. until we get stored procedures with manual transaction
control you have to involve an external agent. for web serving
backend though this isn't a big deal because you have to involve the
browser anyways and your request liftetime is generally short enough
to keep in a database transaction.
> 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.....
With a stored procedure, you could just listen for notifications
(which are not delivered if the transaction rolls back) indefinitely
and/or monitor a queue table. In lieu of that, just cron it up.
merlin
