Re: Last modification time
От | Karsten Hilbert |
---|---|
Тема | Re: Last modification time |
Дата | |
Msg-id | 20060212142143.GA7644@merkur.hilbert.loc обсуждение исходный текст |
Ответ на | Re: Last modification time (Johan Vromans <jvromans@squirrel.nl>) |
Ответы |
Re: Last modification time
|
Список | pgsql-general |
On Sat, Feb 11, 2006 at 09:26:57PM +0100, Johan Vromans wrote: > Doug McNaught <doug@mcnaught.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
В списке pgsql-general по дате отправления: