>> >> 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.
Yes, I do understand that. My issue is that without autonomous transactions procedures are just functions with a different syntax.
As I said, I'd entertain a connection parameter that switched the CALL to call procedures but ideally you'd complain to the server folks to make Procedures useful.
