Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id E2446B5DBD9 for ; Wed, 17 Aug 2011 03:54:05 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 11545-02 for ; Wed, 17 Aug 2011 06:53:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from softlayer.compulab.co.il (50.23.254.54-static.reverse.softlayer.com [50.23.254.54]) by mail.postgresql.org (Postfix) with ESMTP id 8289FB5DBC4 for ; Wed, 17 Aug 2011 03:53:59 -0300 (ADT) Received: from [62.90.235.247] (port=33556 helo=zimbra-mta.compulab.co.il) by softlayer.compulab.co.il with esmtp (Exim 4.69) (envelope-from ) id 1Qta0k-00042E-Tu for pgsql-general@postgresql.org; Wed, 17 Aug 2011 09:53:59 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra-mta.compulab.co.il (Postfix) with ESMTP id E3E017E94AF for ; Wed, 17 Aug 2011 09:53:57 +0300 (IDT) X-Virus-Scanned: amavisd-new at compulab.co.il Received: from zimbra-mta.compulab.co.il ([127.0.0.1]) by localhost (zimbra-mta.compulab.co.il [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh7GL+Q20SlE for ; Wed, 17 Aug 2011 09:53:56 +0300 (IDT) Received: from [10.1.1.27] (sim-pc.compulab.local [10.1.1.27]) by zimbra-mta.compulab.co.il (Postfix) with ESMTP id 59E3B7E94A4 for ; Wed, 17 Aug 2011 09:53:56 +0300 (IDT) Message-ID: <4E4B6571.6080207@compulab.co.il> Date: Wed, 17 Aug 2011 09:53:37 +0300 From: Sim Zacks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: pgsql-general@postgresql.org Subject: Re: Using Postgresql as application server References: <4E498536.9080109@darrenduncan.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - softlayer.compulab.co.il X-AntiAbuse: Original Domain - postgresql.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - compulab.co.il X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.132 tagged_above=-5 required=5 tests=BAYES_00=-1.9, KHOP_DYNAMIC=0.768 X-Spam-Level: X-Archive-Number: 201108/539 X-Sequence-Number: 178821 On 08/15/2011 11:50 PM, Chris Travers wrote: > On Mon, Aug 15, 2011 at 1:44 PM, Darren Duncan 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..... > > Best Wishes, > Chris Travers > We are doing this same sort of thing now. If the transaction goes through, the email record gets written to a table. We have a cron job that calls a database function that processes all emails that have not been processed yet. If the transaction gets rolled back, the email record does not get written to the table and the email does not get sent. In your scenario, if you send the NOTIFY message and then you roll back the transaction, the helper application will still send the email. IOW, doing this outside of the database can more easily break your transactional integrity. Sim