@@ -1078,15 +1078,26 @@ END;
10781078 always sets <literal>FOUND</literal> to true.
10791079 </para>
10801080
1081+ <para>
1082+ For <command>INSERT</>/<command>UPDATE</>/<command>DELETE</> with
1083+ <literal>RETURNING</>, <application>PL/pgSQL</application> reports
1084+ an error for more than one returned row, even when
1085+ <literal>STRICT</literal> is not specified. This is because there
1086+ is no option such as <literal>ORDER BY</> with which to determine
1087+ which affected row should be returned.
1088+ </para>
1089+
10811090 <para>
10821091 If <literal>print_strict_params</> is enabled for the function,
1083- you will get information about the parameters passed to the
1084- query in the <literal>DETAIL</> part of the error message produced
1085- when the requirements of STRICT are not met. You can change this
1086- setting on a system-wide basis by setting
1092+ then when an error is thrown because the requirements
1093+ of <literal>STRICT</> are not met, the <literal>DETAIL</> part of
1094+ the error message will include information about the parameters
1095+ passed to the query.
1096+ You can change the <literal>print_strict_params</>
1097+ setting for all functions by setting
10871098 <varname>plpgsql.print_strict_params</>, though only subsequent
10881099 function compilations will be affected. You can also enable it
1089- on a per-function basis by using a compiler option:
1100+ on a per-function basis by using a compiler option, for example :
10901101<programlisting>
10911102CREATE FUNCTION get_userid(username text) RETURNS int
10921103AS $$
@@ -1100,15 +1111,12 @@ BEGIN
11001111END
11011112$$ LANGUAGE plpgsql;
11021113</programlisting>
1103- </para>
1104-
1105- <para>
1106- For <command>INSERT</>/<command>UPDATE</>/<command>DELETE</> with
1107- <literal>RETURNING</>, <application>PL/pgSQL</application> reports
1108- an error for more than one returned row, even when
1109- <literal>STRICT</literal> is not specified. This is because there
1110- is no option such as <literal>ORDER BY</> with which to determine
1111- which affected row should be returned.
1114+ On failure, this function might produce an error message such as
1115+ <programlisting>
1116+ ERROR: query returned no rows
1117+ DETAIL: parameters: $1 = 'nosuchuser'
1118+ CONTEXT: PL/pgSQL function get_userid(text) line 6 at SQL statement
1119+ </programlisting>
11121120 </para>
11131121
11141122 <note>
@@ -2767,28 +2775,36 @@ END;
27672775 </sect2>
27682776
27692777 <sect2 id="plpgsql-get-diagnostics-context">
2770- <title>Obtaining the Call Stack Context Information</title>
2778+ <title>Obtaining Current Execution Information</title>
2779+
2780+ <para>
2781+ The <command>GET <optional> CURRENT </optional> DIAGNOSTICS</command>
2782+ command retrieves information about current execution state (whereas
2783+ the <command>GET STACKED DIAGNOSTICS</command> command discussed above
2784+ reports information about the execution state as of a previous error).
2785+ This command has the form:
2786+ </para>
27712787
27722788<synopsis>
2773- GET <optional> CURRENT </optional> DIAGNOSTICS <replaceable>variable</replaceable> { = | := } <replaceable>PG_CONTEXT </replaceable> <optional> , ... </optional>;
2789+ GET <optional> CURRENT </optional> DIAGNOSTICS <replaceable>variable</replaceable> { = | := } <replaceable>item </replaceable> <optional> , ... </optional>;
27742790</synopsis>
27752791
27762792 <para>
2777- Calling <command>GET DIAGNOSTICS</command> with status
2778- item <varname >PG_CONTEXT</> will return a text string with line(s) of
2779- text describing the call stack. The first row refers to the
2793+ Currently only one information item is supported. Status
2794+ item <literal >PG_CONTEXT</> will return a text string with line(s) of
2795+ text describing the call stack. The first line refers to the
27802796 current function and currently executing <command>GET DIAGNOSTICS</command>
2781- command. The second and any subsequent rows refer to the calling functions
2782- up the call stack.
2797+ command. The second and any subsequent lines refer to calling functions
2798+ further up the call stack. For example:
27832799
27842800<programlisting>
2785- CREATE OR REPLACE FUNCTION public. outer_func() RETURNS integer AS $$
2801+ CREATE OR REPLACE FUNCTION outer_func() RETURNS integer AS $$
27862802BEGIN
27872803 RETURN inner_func();
27882804END;
27892805$$ LANGUAGE plpgsql;
27902806
2791- CREATE OR REPLACE FUNCTION public. inner_func() RETURNS integer AS $$
2807+ CREATE OR REPLACE FUNCTION inner_func() RETURNS integer AS $$
27922808DECLARE
27932809 stack text;
27942810BEGIN
@@ -2801,8 +2817,9 @@ $$ LANGUAGE plpgsql;
28012817SELECT outer_func();
28022818
28032819NOTICE: --- Call Stack ---
2804- PL/pgSQL function inner_func() line 4 at GET DIAGNOSTICS
2820+ PL/pgSQL function inner_func() line 5 at GET DIAGNOSTICS
28052821PL/pgSQL function outer_func() line 3 at RETURN
2822+ CONTEXT: PL/pgSQL function outer_func() line 3 at RETURN
28062823 outer_func
28072824 ------------
28082825 1
0 commit comments