1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-25 12:03:53 +03:00
Files
postgres/doc/src/sgml/ref/call.sgml
Tom Lane 4b0c3712c5 Fix bugs in plpgsql's handling of CALL argument lists.
exec_stmt_call() tried to extract information out of a CALL statement's
argument list without using expand_function_arguments(), apparently in
the hope of saving a few nanoseconds by not processing defaulted
arguments.  It got that quite wrong though, leading to crashes with
named arguments, as well as failure to enforce writability of the
argument for a defaulted INOUT parameter.  Fix and simplify the logic
by using expand_function_arguments() before examining the list.

Also, move the argument-examination to just after producing the CALL
command's plan, before invoking the called procedure.  This ensures
that we'll track possible changes in the procedure's argument list
correctly, and avoids a hazard of the plan cache being flushed while
the procedure executes.

Also fix assorted falsehoods and omissions in associated documentation.

Per bug #15477 from Alexey Stepanov.

Patch by me, with some help from Pavel Stehule.  Back-patch to v11.

Discussion: https://postgr.es/m/15477-86075b1d1d319e0a@postgresql.org
Discussion: https://postgr.es/m/CAFj8pRA6UsujpTs9Sdwmk-R6yQykPx46wgjj+YZ7zxm4onrDyw@mail.gmail.com
2018-11-04 13:25:39 -05:00

116 lines
2.7 KiB
Plaintext

<!--
doc/src/sgml/ref/call.sgml
PostgreSQL documentation
-->
<refentry id="sql-call">
<indexterm zone="sql-call">
<primary>CALL</primary>
</indexterm>
<refmeta>
<refentrytitle>CALL</refentrytitle>
<manvolnum>7</manvolnum>
<refmiscinfo>SQL - Language Statements</refmiscinfo>
</refmeta>
<refnamediv>
<refname>CALL</refname>
<refpurpose>invoke a procedure</refpurpose>
</refnamediv>
<refsynopsisdiv>
<synopsis>
CALL <replaceable class="parameter">name</replaceable> ( [ <replaceable class="parameter">argument</replaceable> ] [, ...] )
</synopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>
<command>CALL</command> executes a procedure.
</para>
<para>
If the procedure has any output parameters, then a result row will be
returned, containing the values of those parameters.
</para>
</refsect1>
<refsect1>
<title>Parameters</title>
<variablelist>
<varlistentry>
<term><replaceable class="parameter">name</replaceable></term>
<listitem>
<para>
The name (optionally schema-qualified) of the procedure.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><replaceable class="parameter">argument</replaceable></term>
<listitem>
<para>
An input argument for the procedure call.
See <xref linkend="sql-syntax-calling-funcs"/> for the full details on
function and procedure call syntax, including use of named parameters.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Notes</title>
<para>
The user must have <literal>EXECUTE</literal> privilege on the procedure in
order to be allowed to invoke it.
</para>
<para>
To call a function (not a procedure), use <command>SELECT</command> instead.
</para>
<para>
If <command>CALL</command> is executed in a transaction block, then the
called procedure cannot execute transaction control statements.
Transaction control statements are only allowed if <command>CALL</command>
is executed in its own transaction.
</para>
<para>
<application>PL/pgSQL</application> handles output parameters
in <command>CALL</command> commands differently;
see <xref linkend="plpgsql-statements-calling-procedure"/>.
</para>
</refsect1>
<refsect1>
<title>Examples</title>
<programlisting>
CALL do_db_maintenance();
</programlisting>
</refsect1>
<refsect1>
<title>Compatibility</title>
<para>
<command>CALL</command> conforms to the SQL standard.
</para>
</refsect1>
<refsect1>
<title>See Also</title>
<simplelist type="inline">
<member><xref linkend="sql-createprocedure"/></member>
</simplelist>
</refsect1>
</refentry>