On 08/15/2011 11:50 PM, Chris Travers wrote:
> On Mon, Aug 15, 2011 at 1:44 PM, Darren Duncan<darren(at)darrenduncan(dot)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.....
>
> 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