Eugen Dueck wrote:
Now I was hoping for a feature that goes even further than the ones discussed
and allows clients to listen on changes in the database that satisfy real
WHERE clauses, if used on tables, but I could imagine that you can listen for
all changes caused by any DDL or DML statement, including CREATE TABLE and
DROP TABLE.
The motivation behind this request is, that I see lots of processes, connected
to databases, that provide features like the one requested (they can only
report changes that are done by clients through these processes, they don't
notice changes done to the database directly), on the abstraction level
of "business objects". These processes are essentially caches, used by
multiple clients.
So it would be nice to see the one feature I like about these caches added to
Postgres, without having to resort to tricks that force me out of the (SQL)
language, like rules/triggers.
One problem might be that a couple of connection methods (like I think JDBC)
don't allow for asynchronous communication from database to clients, which is
why clients (when I checked out the LISTEN feature in Postgres) have to poll
for changes, but I think it should be possible and maybe there are already
ways to connect to Postgres that allow this?
The tricky bits are (1) reliability, (2) payload size and (3)
transactional semantics. You might find the pg-memcache project of some
interest, since it's handling this for the memcached system.
http://pgfoundry.org/projects/pgmemcache/
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
