On Thu, Oct 18, 2012 at 2:33 PM, Josh Berkus <j...@agliodbs.com> wrote: >> I should also add that this is an switchable sync/asynchronous >> transactional queue, whereas LISTEN/NOTIFY is a synchronous >> transactional queue. > > Thanks for explaining.
New here, I missed half the conversation, but since it's been brought up and (to me wrongfully) dismissed, I'd like to propose: NOTIFY [ALL|ONE] [REMOTE|LOCAL|CLUSTER|DOWNSTREAM] ASYNCHRONOUSLY LISTEN [REMOTE|LOCAL|CLUSTER|UPSTREAM] too for good measure. That ought to work out fine as SQL constructs go, implementation aside. That's not enough for matviews, but it is IMO a good starting point. All you need after that, are triggers for notifying automatically upon insert, and some mechanism to attach triggers to a channel for the receiving side. Since channels are limited to short strings, maybe a different kind of object (but with similar manipulation syntax) ought to be created. The CREATE QUEUE command, in fact, could be creating such a channel. The channel itself won't be WAL-only, just the messages going through it. This (I think) would solve locking issues. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
