On Mon, Aug 15, 2011 at 3:50 PM, Chris Travers <chris.travers@xxxxxxxxx> wrote: > On Mon, Aug 15, 2011 at 1:44 PM, Darren Duncan <darren@xxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
