You could accomplish that with rules.
Make a rule with the where clause you like, then NOTIFY the client.
--
Rod Taylor
This message represents the official view of the voices in my head
----- Original Message -----
From: "Hannu Krosing" <hannu@tm.ee>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Rod Taylor" <rbt@zort.ca>; "Hannu Krosing" <hannu@krosing.net>;
"Dann Corbit" <DCorbit@connx.com>; "Greg Sabino Mullane"
<greg@turnstep.com>; <pgsql-hackers@postgresql.org>
Sent: Tuesday, March 05, 2002 2:45 AM
Subject: [HACKERS] Cache invalidation notification (was: Database
Caching)
> On Mon, 2002-03-04 at 23:50, Tom Lane wrote:
> > "Rod Taylor" <rbt@zort.ca> writes:
> > > Rather than result caching, I'd much rather see an asynchronous
NOTICE
> > > telling my webservers which have RULES firing them off when a
table is
> > > modified.
> >
> > LISTEN/NOTIFY?
>
> But is there an easy way to see which tables affect the query
result,
> something like machine-readable EXPLAIN ?
>
> Another thing that I have thought about Is adding a parameter to
notify,
> so that you can be told _what_ is changed (there is big difference
> between being told that "somebody called" and "Bob called")
>
> There are two ways of doing it
>
> 1) the "wire protocol compatible" way , where the argument to LISTEN
is
> interpreted as a regular expression (or LIKE expression), so that
you
> can do
>
> LISTEN 'ITEM_INVALID:%';
>
> and the receive all notifies for
>
> NOTIFY 'ITEM_INVALID:' || ITEM_ID;
>
> and
>
> NOTIFY 'ITEM_INVALID:ALL';
>
> where the notify comes in as one string
>
> 2) the more general way where you listen on exact "relation" and
notify
> has an argument at both syntax and protocol level, i.e
>
> LISTEN ITEM_INVALID;
>
> and
>
> NOTIFY 'ITEM_INVALID',ITEM_ID;
>
> NOTIFY 'ITEM_INVALID','ALL';
>
> ------------------
> Hannu
>
>
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
