> So yeah, here's another vote for this feature. It doesn't even need to
> happen automagically to be honest, so long as it's really simple for the
> client to turn on (preferably per-statement or per-table).
It might be easiest to shove the caching logic into pgpool instead.
Create an extension of EXPLAIN which returns data in an easy to
understand format for computers so that pgpool can retrieve information
such as a list of tables involved,
Extend LISTEN to be able to listen for a SELECT on a table --
replacement for dynamically adding triggers to send a notify on inserts,
updates, deletes.
Create some kind of generic LISTEN for structural changes. I know SLONY
could make use of triggers on ALTER TABLE, and friends as well.
When pg_pool is told to cache a query, it can get a table list and
monitor for changes. When it gets changes, simply dumps the cache.
