11<!--
2- $Header: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v 1.4 2002/08/29 04:12:02 tgl Exp $
2+ $Header: /cvsroot/pgsql/doc/src/sgml/plpgsql.sgml,v 1.5 2002/08/30 00:28:40 tgl Exp $
33-->
44
55<chapter id="plpgsql">
@@ -1142,11 +1142,20 @@ GET DIAGNOSTICS <replaceable>variable</replaceable> = <replaceable>item</replace
11421142RETURN <replaceable>expression</replaceable>;
11431143</synopsis>
11441144
1145+ RETURN with an expression is used to return from a
1146+ <application>PL/pgSQL</> function that does not return a set.
11451147 The function terminates and the value of
1146- <replaceable>expression</replaceable> will be returned to the
1147- upper executor.
1148+ <replaceable>expression</replaceable> is returned to the caller.
1149+ </para>
1150+
1151+ <para>
1152+ To return a composite (row) value, you must write a record or row
1153+ variable as the <replaceable>expression</replaceable>. When
1154+ returning a scalar type, any expression can be used.
11481155 The expression's result will be automatically cast into the
11491156 function's return type as described for assignments.
1157+ (If you have declared the function to return <type>void</>,
1158+ then the expression can be omitted, and will be ignored in any case.)
11501159 </para>
11511160
11521161 <para>
@@ -1155,6 +1164,28 @@ RETURN <replaceable>expression</replaceable>;
11551164 the function without hitting a RETURN statement, a run-time error
11561165 will occur.
11571166 </para>
1167+
1168+ <para>
1169+ When a <application>PL/pgSQL</> function is declared to return
1170+ <literal>SETOF</literal> <replaceable>sometype</>, the procedure
1171+ to follow is slightly different. The individual items to be returned
1172+ are specified in RETURN NEXT commands, and then a final RETURN with
1173+ no argument is given to indicate that the function is done generating
1174+ items.
1175+
1176+ <synopsis>
1177+ RETURN NEXT <replaceable>expression</replaceable>;
1178+ </synopsis>
1179+
1180+ RETURN NEXT does not actually return from the function; it simply
1181+ saves away the value of the expression (or record or row variable,
1182+ as appropriate for the datatype being returned).
1183+ Execution then continues with the next statement in the
1184+ <application>PL/pgSQL</> function. As successive RETURN NEXT
1185+ commands are executed, the result set is built up. A final
1186+ RETURN, which need have no argument, causes control to exit
1187+ the function.
1188+ </para>
11581189 </sect2>
11591190
11601191 <sect2 id="plpgsql-conditionals">
@@ -1531,8 +1562,8 @@ END LOOP;
15311562 to worry about that, since FOR loops automatically use a cursor
15321563 internally to avoid memory problems.) A more interesting usage is to
15331564 return a reference to a cursor that it has created, allowing the
1534- caller to read the rows. This providesa way to return row sets
1535- from functions.
1565+ caller to read the rows. This providesan efficient way to return
1566+ large row sets from functions.
15361567 </para>
15371568
15381569 <sect2 id="plpgsql-cursor-declarations">
@@ -1794,19 +1825,27 @@ COMMIT;
17941825RAISE <replaceable class="parameter">level</replaceable> '<replaceable class="parameter">format</replaceable>' <optional>, <replaceable class="parameter">variable</replaceable> <optional>...</optional></optional>;
17951826</synopsis>
17961827
1797- Possible levels are DEBUG (write the message into the postmaster log),
1798- NOTICE (write the message into the postmaster log and forward it to
1799- the client application) and EXCEPTION (raise an error,
1800- aborting the transaction).
1828+ Possible levels are <literal>DEBUG</literal> (write the message to
1829+ the server log), <literal>LOG</literal> (write the message to the
1830+ server log with a higher priority), <literal>INFO</literal>,
1831+ <literal>NOTICE</literal> and <literal>WARNING</literal> (write
1832+ the message to the server log and send it to the client, with
1833+ respectively higher priorities), and <literal>EXCEPTION</literal>
1834+ (raise an error and abort the current transaction). Whether error
1835+ messages of a particular priority are reported to the client,
1836+ written to the server log, or both is controlled by the
1837+ <option>SERVER_MIN_MESSAGES</option> and
1838+ <option>CLIENT_MIN_MESSAGES</option> configuration variables. See
1839+ the <citetitle>PostgreSQL Administrator's Guide</citetitle> for more
1840+ information.
18011841 </para>
18021842
18031843 <para>
1804- Inside the format string, <literal>%</literal> is replaced by the next
1805- optional argument's external representation.
1806- Write <literal>%%</literal> to emit a literal <literal>%</literal>.
1807- Note that the optional arguments must presently
1808- be simple variables, not expressions, and the format must be a simple
1809- string literal.
1844+ Inside the format string, <literal>%</literal> is replaced by the
1845+ next optional argument's external representation. Write
1846+ <literal>%%</literal> to emit a literal <literal>%</literal>. Note
1847+ that the optional arguments must presently be simple variables,
1848+ not expressions, and the format must be a simple string literal.
18101849 </para>
18111850
18121851 <!--
@@ -1820,8 +1859,9 @@ RAISE <replaceable class="parameter">level</replaceable> '<replaceable class="pa
18201859<programlisting>
18211860RAISE NOTICE ''Calling cs_create_job(%)'',v_job_id;
18221861</programlisting>
1823- In this example, the value of v_job_id will replace the % in the
1824- string.
1862+
1863+ In this example, the value of v_job_id will replace the
1864+ <literal>%</literal> in the string.
18251865 </para>
18261866
18271867 <para>
@@ -1852,12 +1892,12 @@ RAISE EXCEPTION ''Inexistent ID --> %'',user_id;
18521892 </para>
18531893
18541894 <para>
1855- Thus, the only thing <application>PL/pgSQL</application> currently does when it encounters
1856- an abort during execution of a function or trigger
1857- procedure is to write some additional NOTICE level log messages
1858- telling in which function and where (line number and type of
1859- statement) this happened. The error always stops execution of
1860- the function.
1895+ Thus, the only thing <application>PL/pgSQL</application>
1896+ currently does when it encounters an abort during execution of a
1897+ function or trigger procedure is to write some additional
1898+ <literal>NOTICE</literal> level log messages telling in which
1899+ function and where (line number and type of statement) this
1900+ happened. The error always stops execution of the function.
18611901 </para>
18621902 </sect2>
18631903 </sect1>