From: | Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Last modification time |
Date: | 2006-02-12 14:21:43 |
Message-ID: | 20060212142143.GA7644@merkur.hilbert.loc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, Feb 11, 2006 at 09:26:57PM +0100, Johan Vromans wrote:
> Doug McNaught <doug(at)mcnaught(dot)org> writes:
> > Yeah, LISTEN/NOTIFY is definitely a lighter-weight solution--I didn't
> > think of that before.
>
> LISTEN/NOTIFY looks like a synchronisation mechanism. You can notify a
> subscriber that something happened. But in my case, the report
> generating program runs only occasionally and will not be permanently
> running subscribed. I'm not sure how to use LISTEN/NOTIFY for that.
You add ON INSERT/UPDATE/NOTIFY triggers to the tables you
are interested in which fire a given NOTIFY. The report
generator would LISTEN for that while connected.
However, given your above description why does it not
suffice to regenerate the report whenever the report
generator connects ? If you want to do so only when the
table has actually changed you might add a last_modified
timestamp column with a default of now(), remember that in
the report generator and later do
select exists(select 1 from <table> where last_modified > <old_last_modified>)
to check whether you need to regenerate the report.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Moseley | 2006-02-12 16:03:07 | Re: Limiting with a left outer join |
Previous Message | Doug McNaught | 2006-02-12 13:57:41 | Re: Last modification time |