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.
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 . We ought not to break its users’ code, no?