Re: Cache invalidation notification (was: Database Caching)

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(at)tm(dot)ee>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Rod Taylor" <rbt(at)zort(dot)ca>; "Hannu Krosing" <hannu(at)krosing(dot)net>;
"Dann Corbit" <DCorbit(at)connx(dot)com>; "Greg Sabino Mullane"
<greg(at)turnstep(dot)com>; <pgsql-hackers(at)postgresql(dot)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(at)zort(dot)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
>