I find it really hard to adapt to the single `Listener.Notify` channel for listening on different Postgres channels, especially since I listen/unlisten somewhat dynamically. Right now, I'm using the first stab at LISTEN/NOTIFY, which accepts a channel to write notifications to. I don't like this aspect of it--I think that having the Listener manage the channel is more sensible--but I do like that there's a 1-to-1 correspondence between Postgres channels and Go channels, and that the result (in the larger, world-mutating sense; not the return value) of the function call is relatively local to the given `Listen` call site.

More concretely, in my current app, in the setup code, I pass a Listener to several functions, and have each function issue whatever Listen call(s) it needs, process the results, deserialize the JSON-encoded payloads, and send that on a separate channel so that I can deal with Go structs instead of string payloads. The functions look something like this:

```go
func fooListen(listener pq.Listener) (<-chan *Foo, error) {
        notifCh := make(chan *pq.Notification)
        err := listener.Listen("my_foo_channel", notifCh)
        if err != nil {
                return nil, fmt.Errorf("could not listen for notifications: %v\n", err)
        }
        fooCh := make(chan *Foo)
        go func() {
                for notif := range notifCh {
                        payload := notif.Extra
                        var foo Foo
                        err := json.Unmarshal([]byte(payload), &Foo)
                        if err != nil {
                                log.Fatalf("error parsing foo notification: %v\n", err)
                        }
                        respCh <- &response
                }
        }()
        return fooCh, nil
}
```

In your approach, I'd need to centralize reads from the `Listener.Notify` channel, and dispatch to the right processing code according to the message payload myself, no? This becomes more difficult if I need to add/remove listeners dynamically, because whatever is draining the `Listener.Notify` queue will need to, e.g., accept callbacks for what to do for each type of message if I don't want to hardcode the full set of possibilities up front.

Or is there a better way to do that? How do you envisage dynamic listen/notify?