On Tue, Aug 25, 2020 at 08:38:11PM +0200, Peter Eisentraut wrote:
> On 2020-08-24 18:00, Bruce Momjian wrote:
> > - command, a procedure is called explicitly using
> > - the <xref linkend="sql-call"/> statement.
> > + command, a procedure is called in isolation using
> > + the <xref linkend="sql-call"/> command. If the CALL command is not
> > + part of an explicit transaction, a procedure can commit, rollback,
> > + and begin new transactions during its execution, which is not possible
> > + in functions.
>
> There are additional conditions for when a procedure can do transaction
> control, and it also depends on the language. It's not clear how much
> detail we should give in a general section like this. Often people read
> this and then wonder why it doesn't work.
I have updated the patch to mention it is dependend on the server-side
language.
--
Bruce Momjian <[email protected]> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml
index 6de464c654..732d935521 100644
--- a/doc/src/sgml/xfunc.sgml
+++ b/doc/src/sgml/xfunc.sgml
@@ -84,8 +84,11 @@
A procedure is a database object similar to a function. The difference is
that a procedure does not return a value, so there is no return type
declaration. While a function is called as part of a query or DML
- command, a procedure is called explicitly using
- the <xref linkend="sql-call"/> statement.
+ command, a procedure is called in isolation using
+ the <xref linkend="sql-call"/> command. If the CALL command is not
+ part of an explicit transaction, a procedure in many server-side
+ languages can commit, rollback, and begin new transactions during
+ its execution, which is not possible in functions.
</para>
<para>
