Skip site navigation (1) Skip section navigation (2)

Re: Pet Peeves?

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Guy Rouillier <guyr-ml1(at)burntmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Pet Peeves?
Date: 2009-02-04 18:42:27
Message-ID: 1233772947.4500.334.camel@ebony.2ndQuadrant (view raw or flat)
Thread:
Lists: pgsql-general
On Wed, 2009-02-04 at 14:09 +0900, Craig Ringer wrote:
> Guy Rouillier wrote:
> > Craig Ringer wrote:
> >> An internal job scheduler with the ability to fire jobs on certain 
> >> events as well as on a fixed schedule could be particularly handy in 
> >> conjunction with true stored procedures that could explicitly manage 
> >> transactions.
> > 
> > Craig, what kind of "events" are you thinking about?  Triggers are 
> > already pieces of code that run upon "certain events", namely insert, 
> > update or delete events.  What others do you have in mind?
> 
> That's a good point, actually. I can't think of much you can't do with a 
> trigger (SECURITY DEFINER if necessary) on a table. Not thinking straight.

True, but the trigger does its work while the user waits. If we have a
30 min task, we don't want to just tack that on to the end of a random
insert.

As A.M. says elsewhere, it would be good to have a trigger that fired a
NOTIFY that was picked up by a scheduled job that LISTENs every 10
minutes for certain events.

We need a place for code that is *not* directly initiated by a user's
actions, yet works as part of a closed loop system.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


In response to

Responses

pgsql-general by date

Next:From: David WallDate: 2009-02-04 19:02:49
Subject: Array, bytea and large objects
Previous:From: Sam MasonDate: 2009-02-04 18:38:46
Subject: Re: field with Password

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group