Hello Peter,
>> I'm wary of changing the SPI_commit and SPI_rollback interfaces which are
>> certainly being used outside the source tree and could break countless
>> code, and it seems quite unclean that commit and rollback would do
>> anything else but committing or rollbacking.
>
> These are new as of PG11 and are only used by PL implementations that
Ok, but that does not make it right to break them immediately in PG12.
> support transaction control in procedures, of which there are very few.
> We could write separate functions for the "and chain" variants, but I
> hope that eventually all PLs will support chaining (because that's
> really what you ought to be using in procedures), and so then the
> non-chaining interfaces would end up being unused.
One of my issue is that the function name does not really reflect its
updated behavior. I'd be okay with additional _and_chain functions,
although I'm unsure whether one is really needed because it seems that you
need to handle things differently afterwards anyway on the language side.
>> ISTM that it should be kept as is and only managed from the PL/pgsql
>> exec_stmt_* functions, which have to be adapted anyway. That would
>> minimise changes and not break existing code.
>
> But we want other PLs to be able to use this too.
Sure, but I do not see that as a particular issue. PLs need to be extended
to provide a syntax for the new feature anyway, it would not be automatic.
If you really feel there is an issue, then do _and_chain functions, but if
the afterwards code needs to check whether it was and chain and adjust
other internal settings, I'm not sure it is really worth it.
--
Fabien.
