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

Re: fine grained trigger time specification...

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Erik Thiele <erik(at)thiele-hydraulik(dot)de>
Cc: Bruno Wolff III <bruno(at)wolff(dot)to>, pgsql-sql(at)postgresql(dot)org
Subject: Re: fine grained trigger time specification...
Date: 2004-03-23 17:22:29
Message-ID: 20040323092023.V89245@megazone.bigpanda.com (view raw or flat)
Thread:
Lists: pgsql-sql
On Tue, 23 Mar 2004, Erik Thiele wrote:

> On Tue, 23 Mar 2004 10:17:31 -0600
> Bruno Wolff III <bruno(at)wolff(dot)to> wrote:
>
> > On Tue, Mar 23, 2004 at 15:19:13 +0100,
> >   Erik Thiele <erik(at)thiele-hydraulik(dot)de> wrote:
> > > now sadly i am getting this kind of problem:
> > >
> > >
> > > zeit=> insert into a select
> > > nextval('delmeseq'),personalnumber,datum,datum from calendar where
> > > type=10409;
> > > INSERT 0 581   <-- see, 581 inserts which is pretty much :)
> > > zeit=> commit;  <--  now i have to wait for 581 calls of alwayscheck
> > >
> > >
> > > since alwayscheck is not the fastest function on earth, i'd like to have
> > > it called on commit time if at least one of table a or b was modified,
> > > but always only once per commit. is there a way to formulate this:
> > >
> > > ARRANGE FOR CALL OF FUNCTION alwayscheck() ON COMMIT WHEN AT LEAST ONE
> > > OF TABLE a OR TABLE b WAS MODIFIED BUT CALL THE FUNCTION AT MOST ONE
> > > TIME;

I didn't see the original, but...

One way to do hack this up is triggers which insert a row into another
holding table if and only if it hasn't already (something like transaction
id or some such - something you don't need to worry about concurrency
with) which itself has a deferred trigger on insert (which should probably
remove the row as part of its behavior).

In response to

pgsql-sql by date

Next:From: xvxDate: 2004-03-23 18:30:36
Subject: Re: could not create shared memory segment: Invalid argument
Previous:From: Erik ThieleDate: 2004-03-23 16:56:25
Subject: Re: fine grained trigger time specification...

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