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

func (p*PGPubsub)PublishWithinTx(eventstring,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(eventstring,message []byte,tx database.Store)error {_=tx// ignoredreturnp.PublishTx(event,message)}

But it will require some changes indatabase.Store andPGPubSub

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 callingPublish from within existing transaction? For ex.: add smth like this:

func (p*PGPubsub)PublishWithinTx(eventstring,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(eventstring,message []byte,tx database.Store)error {_=tx// ignoredreturnp.PublishTx(event,message)}

But it will require some changes indatabase.Store andPGPubSub

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.