"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Tue, Jul 13, 2021 at 8:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The protocol contract for that is that NOTIFY is delivered *between*
>> transactions.
> This is saying "We must not RECEIVE a notification unless the client is
> prepared to handle it - idle and not within a transaction."
Right.
> So, the choice to delay releasing the notification upon committing the
> first transaction of a chain is a design choice.
Sure, you could argue that. But look at it from the client's side.
How would it detangle its response to the notify event from whatever
it's doing as part of the chained transaction? You don't want to
risk the notify-response action failing because of a problem in the
chained transaction, nor vice versa, because they are independent things.
(Whatever the notify is about *did* commit, independently of what
you are doing.) It's very hard to see how you could do that sanely,
other than by delaying handling the notify event till after you're out
of the chain.
Another angle is that (I think) the proposed patch would allow notifies
to be delivered during a commit that happens inside a procedure. At
that point, the client doesn't even have control of the connection
with which to do something in response to the notify.
There might be value in the aspect of the patch that sends statistics
upon commit/rollback. But NOTIFY is a *totally* different animal.
The fact that the code happens to be physically adjacent in the current
implementation doesn't mean that the semantic constraints are similar.
regards, tom lane
