Re: chained transactions
От | Fabien COELHO |
---|---|
Тема | Re: chained transactions |
Дата | |
Msg-id | alpine.DEB.2.21.1901061407120.30093@lancre обсуждение исходный текст |
Ответ на | Re: chained transactions (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: