1
1
<!--
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 $
3
3
-->
4
4
5
5
<chapter id="plpgsql">
@@ -1142,11 +1142,20 @@ GET DIAGNOSTICS <replaceable>variable</replaceable> = <replaceable>item</replace
1142
1142
RETURN <replaceable>expression</replaceable>;
1143
1143
</synopsis>
1144
1144
1145
+ RETURN with an expression is used to return from a
1146
+ <application>PL/pgSQL</> function that does not return a set.
1145
1147
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.
1148
1155
The expression's result will be automatically cast into the
1149
1156
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.)
1150
1159
</para>
1151
1160
1152
1161
<para>
@@ -1155,6 +1164,28 @@ RETURN <replaceable>expression</replaceable>;
1155
1164
the function without hitting a RETURN statement, a run-time error
1156
1165
will occur.
1157
1166
</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>
1158
1189
</sect2>
1159
1190
1160
1191
<sect2 id="plpgsql-conditionals">
@@ -1531,8 +1562,8 @@ END LOOP;
1531
1562
to worry about that, since FOR loops automatically use a cursor
1532
1563
internally to avoid memory problems.) A more interesting usage is to
1533
1564
return a reference to a cursor that it has created, allowing the
1534
- caller to read the rows. This provides a way to return row sets
1535
- from functions.
1565
+ caller to read the rows. This provides an efficient way to return
1566
+ large row sets from functions.
1536
1567
</para>
1537
1568
1538
1569
<sect2 id="plpgsql-cursor-declarations">
@@ -1794,19 +1825,27 @@ COMMIT;
1794
1825
RAISE <replaceable class="parameter">level</replaceable> '<replaceable class="parameter">format</replaceable>' <optional>, <replaceable class="parameter">variable</replaceable> <optional>...</optional></optional>;
1795
1826
</synopsis>
1796
1827
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.
1801
1841
</para>
1802
1842
1803
1843
<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.
1810
1849
</para>
1811
1850
1812
1851
<!--
@@ -1820,8 +1859,9 @@ RAISE <replaceable class="parameter">level</replaceable> '<replaceable class="pa
1820
1859
<programlisting>
1821
1860
RAISE NOTICE ''Calling cs_create_job(%)'',v_job_id;
1822
1861
</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.
1825
1865
</para>
1826
1866
1827
1867
<para>
@@ -1852,12 +1892,12 @@ RAISE EXCEPTION ''Inexistent ID --> %'',user_id;
1852
1892
</para>
1853
1893
1854
1894
<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.
1861
1901
</para>
1862
1902
</sect2>
1863
1903
</sect1>
0 commit comments