Eh, maybe. Realistically, to a first order approximation, the user wants to reconnect 100% of the time. The first thing I did when wrapping the previous iteration of LISTEN/NOTIFY support here in a utility function was building in reconnect logic.

I think if we don't include some reconnection support, 80% of users will have to build their own in utility functions (complete with redistributing the notification channels if we go the route that we had both suggested of `pq.Listener`-owned channels). Of the remaining, 19.9% will have brittle code because they didn't consider connectivity issues, and 0.1% will have some special needs that they'll want to handle differently.

I think the `func(error) bool` reconnection callback would be fairly general and allow us to reuse all the existing notification channels. Are there cases that it doesn't address?

The other alternative would be to skip reconnection in the primary interface, but offer a reconnecting utility wrapper (but with `Listener`-owned notification channels, the wrapper would have to shuffle around all the notification events to get this to work).