@@ -1387,11 +1387,11 @@ EXECUTE format('UPDATE tbl SET %I = $1 WHERE key = $2', colname)
1387
1387
command, which has the form:
1388
1388
1389
1389
<synopsis>
1390
- GET DIAGNOSTICS <replaceable>variable</replaceable> = <replaceable>item</replaceable> <optional> , ... </optional>;
1390
+ GET <optional> CURRENT </optional> DIAGNOSTICS <replaceable>variable</replaceable> = <replaceable>item</replaceable> <optional> , ... </optional>;
1391
1391
</synopsis>
1392
1392
1393
1393
This command allows retrieval of system status indicators. Each
1394
- <replaceable>item</replaceable> is a key word identifying a state
1394
+ <replaceable>item</replaceable> is a key word identifying a status
1395
1395
value to be assigned to the specified variable (which should be
1396
1396
of the right data type to receive it). The currently available
1397
1397
status items are <varname>ROW_COUNT</>, the number of rows
@@ -2522,16 +2522,6 @@ END;
2522
2522
</para>
2523
2523
</tip>
2524
2524
2525
- <para>
2526
- Within an exception handler, the <varname>SQLSTATE</varname>
2527
- variable contains the error code that corresponds to the
2528
- exception that was raised (refer to <xref
2529
- linkend="errcodes-table"> for a list of possible error
2530
- codes). The <varname>SQLERRM</varname> variable contains the
2531
- error message associated with the exception. These variables are
2532
- undefined outside exception handlers.
2533
- </para>
2534
-
2535
2525
<example id="plpgsql-upsert-example">
2536
2526
<title>Exceptions with <command>UPDATE</>/<command>INSERT</></title>
2537
2527
<para>
@@ -2568,11 +2558,112 @@ LANGUAGE plpgsql;
2568
2558
SELECT merge_db(1, 'david');
2569
2559
SELECT merge_db(1, 'dennis');
2570
2560
</programlisting>
2571
- This example assumes the <literal>unique_violation</> error is caused by
2572
- the <command>INSERT</>, and not by an <command>INSERT</> trigger function
2573
- on the table.
2561
+
2562
+ This coding assumes the <literal>unique_violation</> error is caused by
2563
+ the <command>INSERT</>, and not by, say, an <command>INSERT</> in a
2564
+ trigger function on the table. More safety could be had by using the
2565
+ features discussed next to check that the trapped error was the one
2566
+ expected.
2574
2567
</para>
2575
2568
</example>
2569
+
2570
+ <sect3 id="plpgsql-exception-diagnostics">
2571
+ <title>Obtaining information about an error</title>
2572
+
2573
+ <para>
2574
+ Exception handlers frequently need to identify the specific error that
2575
+ occurred. There are two ways to get information about the current
2576
+ exception in <application>PL/pgSQL</>: special variables and the
2577
+ <command>GET STACKED DIAGNOSTICS</command> command.
2578
+ </para>
2579
+
2580
+ <para>
2581
+ Within an exception handler, the special variable
2582
+ <varname>SQLSTATE</varname> contains the error code that corresponds to
2583
+ the exception that was raised (refer to <xref linkend="errcodes-table">
2584
+ for a list of possible error codes). The special variable
2585
+ <varname>SQLERRM</varname> contains the error message associated with the
2586
+ exception. These variables are undefined outside exception handlers.
2587
+ </para>
2588
+
2589
+ <para>
2590
+ Within an exception handler, one may also retrieve
2591
+ information about the current exception by using the
2592
+ <command>GET STACKED DIAGNOSTICS</command> command, which has the form:
2593
+
2594
+ <synopsis>
2595
+ GET STACKED DIAGNOSTICS <replaceable>variable</replaceable> = <replaceable>item</replaceable> <optional> , ... </optional>;
2596
+ </synopsis>
2597
+
2598
+ Each <replaceable>item</replaceable> is a key word identifying a status
2599
+ value to be assigned to the specified variable (which should be
2600
+ of the right data type to receive it). The currently available
2601
+ status items are:
2602
+
2603
+ <table id="plpgsql-exception-diagnostics-values">
2604
+ <title>Error diagnostics values</title>
2605
+ <tgroup cols="3">
2606
+ <thead>
2607
+ <row>
2608
+ <entry>Name</entry>
2609
+ <entry>Type</entry>
2610
+ <entry>Description</entry>
2611
+ </row>
2612
+ </thead>
2613
+ <tbody>
2614
+ <row>
2615
+ <entry><literal>RETURNED_SQLSTATE</literal></entry>
2616
+ <entry>text</entry>
2617
+ <entry>the SQLSTATE error code of the exception</entry>
2618
+ </row>
2619
+ <row>
2620
+ <entry><literal>MESSAGE_TEXT</literal></entry>
2621
+ <entry>text</entry>
2622
+ <entry>the text of the exception's primary message</entry>
2623
+ </row>
2624
+ <row>
2625
+ <entry><literal>PG_EXCEPTION_DETAIL</literal></entry>
2626
+ <entry>text</entry>
2627
+ <entry>the text of the exception's detail message, if any</entry>
2628
+ </row>
2629
+ <row>
2630
+ <entry><literal>PG_EXCEPTION_HINT</literal></entry>
2631
+ <entry>text</entry>
2632
+ <entry>the text of the exception's hint message, if any</entry>
2633
+ </row>
2634
+ <row>
2635
+ <entry><literal>PG_EXCEPTION_CONTEXT</literal></entry>
2636
+ <entry>text</entry>
2637
+ <entry>line(s) of text describing the call stack</entry>
2638
+ </row>
2639
+ </tbody>
2640
+ </tgroup>
2641
+ </table>
2642
+ </para>
2643
+
2644
+ <para>
2645
+ If the exception did not set a value for an item, an empty string
2646
+ will be returned.
2647
+ </para>
2648
+
2649
+ <para>
2650
+ Here is an example:
2651
+ <programlisting>
2652
+ DECLARE
2653
+ text_var1 text;
2654
+ text_var2 text;
2655
+ text_var3 text;
2656
+ BEGIN
2657
+ -- some processing which might cause an exception
2658
+ ...
2659
+ EXCEPTION WHEN OTHERS THEN
2660
+ GET STACKED DIAGNOSTICS text_var1 = MESSAGE_TEXT,
2661
+ text_var2 = PG_EXCEPTION_DETAIL,
2662
+ text_var3 = PG_EXCEPTION_HINT;
2663
+ END;
2664
+ </programlisting>
2665
+ </para>
2666
+ </sect3>
2576
2667
</sect2>
2577
2668
</sect1>
2578
2669
0 commit comments