@dannykopping is it possible to use another approach, and allow calling Publish from within existing transaction?
For ex.: add smth like this:

func (p *PGPubsub) PublishWithinTx(event string, message []byte, tx database.Store) error {
   tx.ExecContext(context.Background(), `select pg_notify(`+pq.QuoteLiteral(event)+`, $1)`, message)
}

Implementations which doesn't support txs may implement it:

func (p *InMemPubSub) PublishWithinTx(event string, message []byte, tx database.Store) error {
    _ = tx // ignored
   return p.PublishTx(event, message)
}

But it will require some changes in database.Store and PGPubSub

Because we impose restrictions on ourselves, every time we need to use Publish within tx - we have to come up with workaround like in this PR.

@dannykopping is it possible to use another approach, and allow calling Publish from within existing transaction? For ex.: add smth like this:

func (p *PGPubsub) PublishWithinTx(event string, message []byte, tx database.Store) error {
   tx.ExecContext(context.Background(), `select pg_notify(`+pq.QuoteLiteral(event)+`, $1)`, message)
}

Implementations which doesn't support txs may implement it:

func (p *InMemPubSub) PublishWithinTx(event string, message []byte, tx database.Store) error {
    _ = tx // ignored
   return p.PublishTx(event, message)
}

But it will require some changes in database.Store and PGPubSub

Because we impose restrictions on ourselves, every time we need to use Publish within tx - we have to come up with workaround like in this PR.

@evgeniy-scherbina I'll defer to @spikecurtis about your above question. However, I would imagine that we wouldn't want to overwhelm the API with knowledge of in- or out-of-transaction considerations. NOTIFYs within transactions (docs) have some semantics which may not always be desireable.

There are also some problems around 2PC ("A transaction that has executed NOTIFY cannot be prepared for two-phase commit."), and in general it just makes pubsub a bit less deterministic.