Add asynchronous notification support

[sfackler]

A handler based approach like set_notice_handler doesn't really make sense here, since the common response to a notification is probably going to be querying for updated data.

Something like libpq's PGnotices seems like the most straightforward solution, but both blocking and polling options both seem like they'd be useful.

[oberstet]

+1 for NOTIFY support.

Some notes:

Besides issuing a query blocking on NOTIFY, some PG libs also supports a 2nd mode: add the file descriptor of the connection LISTENing to a select/poll'ed set (e.g. http://pythonhosted.org/psycopg2/advanced.html#asynchronous-notifications).

In fact, psycopg2 allows to run all queries in an async style (http://pythonhosted.org/psycopg2/advanced.html#asynchronous-support) making use of the async support in libpq (http://www.postgresql.org/docs/current/static/libpq-async.html).

[sfackler]

Rust's new IO system doesn't currently have support for select/poll/etc. One option that may be reasonable in the sort term is to have a next_block method on the PostgresNotificationIterator that will block on the socket for a notification if there aren't any queued up. It wouldn't allow you to wait for a notification or some other input like select would, but it'd get you most of the way there.

Async queries shouldn't be too tough to add. It's a little sad that they'll make the interface more dangerous at runtime since you can't make any other queries while an async query is executing. Right now, the closest thing to this is the lazy_query API on statements inside of a transaction. You still have to wait for the first result batch to come back in this case, though, which may not be ideal if it's an expensive query.

[oberstet]

"Rust's new IO system doesn't currently have support for select/poll/etc.": that is .. limiting. OT: what about libuv and Rust? Is that usable / will it get the "standard" IO system with Rust?

[sfackler]

The new IO system (std::rt::io) is backed by libuv and will soon replace the legacy IO system. Rust-Postgres uses the new IO system currently as well. There has been some work towards supporting select in std::select but it isn't working yet. @alexcrichton is doing most of the work on getting the new IO system working currently I think.

[msierks]

+1

[sfackler]

@msierks What kind of functionality are you looking for? The options I see are a nonblocking iterator (sort of what we have now), a blocking iterator, or a callback based system, or some combination of the above.

[msierks]

I like the non-blocking iterator, but a blocking one with an optional timeout would be great if possible. Similarly to the wait_for_notify method in the ruby PostgreSQL adapter.

http://www.rubydoc.info/gems/pg/PG/Connection#wait_for_notify-instance_method

Currently, the only issue with the non-blocking iterator is I cannot periodically check the iterator for new notifications. I don't receive the notifications unless I do some other sql actions. Does that sound right or am I doing something improperly ?

[sfackler]

Yep, that's correct right now. Makes sense!

[sfackler]

There's now a next_block method on Notifications: http://sfackler.github.io/doc/postgres/struct.Notifications.html#method.next_block. A version that times out is blocked on rust-lang/rust#19328.

[sfackler]

@msierks next_block_for is now implemented. Does the current functionality cover your needs?

http://sfackler.github.io/doc/postgres/struct.Notifications.html#method.next_block_for

[msierks]

@sfackler I haven't had a chance to implement it yet, but I believe it should. I will let you know once I have.

[msierks]

@sfackler Yup, this fits my needs perfectly. Thanks! :)

[sfackler]

Cool! I'm going to close this issue. If future feature requests come up, feel free to open a new one.