Re: NOTIFY in multi-statement PQexec() not sent outside of transaction

Thanks for the thoughts David. I assume there is a regression test suite
for postgres? In addition to documentation, can a test case be added that
will ensure the present behavior remains unchanged until someone thinks
about fixing it? This will serve as another reminder about the issue?

On Mon, Apr 20, 2020 at 3:39 PM David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com> wrote:

> On Mon, Apr 20, 2020 at 1:27 PM John Muehlhausen <jgm(at)jgm(dot)org> wrote:
>
>>
>>>
>>> > My perspective as a libpq user is that multi-statement PQexec() should
>>> have
>>> > the same effects as multiple PQexec() calls other than for the former
>>> > dropping the results of all but the most recent statement.
>>>
>>
>
>> Still, even without considering my usage, I find it odd that this would
>> not be considered a bug, for the reason in my first sentence above. The
>> current behavior means that the user has to think about transactions "and
>> something else" when reasoning about the effects of statements. I would
>> vote to remove the "and something else" which would then remove the need to
>> augment the current documentation. As it stands, at minimum, the
>> documentation needs to warn the user that similar notify effects are
>> unachievable in the multi-statement realm?
>>
>
> The deeper into the architecture the change the more resistant to change
> it should be. This is pretty low-level and the benefits don't seem that
> great. It is functional, and the usage pattern involved, multi-statement
> commands, is one that is actively discouraged - so from my perspective
> classifying this as a bug that the core team should fix is unappealing. If
> someone wants to offer up a feature enhancement patch for critique then
> we'll see.
>
> David J.
>