[ANN] hasql-listen-notify: LISTEN/NOTIFY support for hasql

Hi all,

We’ve put together a small addition to the hasql ecosystem: hasql-listen-notify (GitHub source).

Users may be already familiar with hasql-notifications, the first library in the hasql ecosystem to provide asynchronous notification support. So here are a few reasons you may consider switching:

  • More “hasqly” API featuring Session where appropriate.
  • No dependency on hasql-pool.
  • Safer identifier escaping that uses PQescapeIdentifier() rather than a custom Haskell implementation.
  • More minimal/fundamental poll / await combinators for receiving notifications, rather than a monolithic waitForNotifications that accepts a callback.
  • Correct reconnection handling: it’s possible for a libpq connection object to be temporarily disconnected from Postgres, and this library will not throw an exception in this case.
  • Backend PID from notification payload is not thrown away.

Thanks and don’t hesitate to file an issue or ask a question.

8 Likes

Thank you very much for working on this!

4 Likes

How stable would you say this new library is? Has it been used in production, and for how long?

I’m also wondering a bit why there should be two libraries – could the existing one not have been taken in this direction? I don’t see any bug reports over at hasql-notifications about e.g. the connection issue.

I would consider it “experimental”, though it is extremely small and mostly wrapping existing postgresql-libpq functionality in a hasql veneer. I’m using it on a weekend project of mine (https://poll.supply), so you could say it’s being used in production, but it’s not being hammered.

About why two libraries: well, hasql-notifications has a completely different interface, so it’s a different library :wink: . We ought not to break its users’ code, no?

And about the issue: it was reported, and subsequently closed by the reporter, but without a fix: Don't panic on waitForNotifications · Issue #4 · diogob/hasql-notifications · GitHub

2 Likes