> The tricky case is when you dont know when and how the database will
be
> updated. That would need an insert/update/delete trigger on each and
> every table that contributes to the query, either explicitly ot
through
> rule expansion. Doing that from client side would a) be difficult
and b)
> probably too slow to be of any use. To do it in a general fashion
wopuld
> also need a way to get the expanded query tree for a query to see
which
> tables the query depends on.
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.
Let the webserver hold the cache (as they do now in my case, and in
slashdots) but it gives a way that the database can tell all those
involved to drop the cache and rebuild. Currently I accomplish this
with a timestamp on a single row table. Could probably accomplish it
with a periodic SELECT TRUE and watch for the notice -- but in my case
I need to support other dbs as well.