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.
