>>
>> I'm sure that new users who start using PostgreSQL 11+, and those
>> migrating from other DBMSs, would have that kind of viewpoint. They'd
>> naturally be creating stored procedures for various complex reusable
>> processing (that does not necessarily need to commit/rollback
>> transactions within the procedure).
>
>
> I presume you have use cases that do not do transactions ?
>
What I was getting at here is that stored procedures can participate
in transactions, without having to control them (i.e. without issuing
COMMIT/ROLLBACK themselves).
For example, a client JDBC-based application might start a transaction
(auto-commit=FALSE), and invoke a couple of stored procedures as part
of the transaction, and then COMMIT the transaction (or ROLLBACK if an
exception is raised). The stored procedures in this case might
UPDATE/INSERT records; they are participating in the transaction, but
not explicitly controlling it.
Greg Nancarrow
Fujitsu Australia