Re: [HACKERS] patch: enhanced get diagnostics statement 2
Pavel Stehule writes: > 2011/7/14 Alvaro Herrera : >> Thanks ... I expect you're going to resubmit the patch based on David's >> last version and my comments? > yes, see a attachment Applied with some editorial adjustments. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: enhanced get diagnostics statement 2
Hello 2011/7/14 Alvaro Herrera : > Excerpts from Pavel Stehule's message of jue jul 14 16:25:56 -0400 2011: >> 2011/7/14 Alvaro Herrera : >> > A couple items for this patch: > >> it is good idea > > Thanks ... I expect you're going to resubmit the patch based on David's > last version and my comments? > yes, see a attachment Regards Pavel > -- > Álvaro Herrera > The PostgreSQL Company - Command Prompt, Inc. > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > *** ./doc/src/sgml/plpgsql.sgml.orig 2011-07-15 07:53:03.069787671 +0200 --- ./doc/src/sgml/plpgsql.sgml 2011-07-15 08:36:00.504591377 +0200 *** *** 1387,1393 command, which has the form: ! GET DIAGNOSTICS variable = item , ... ; This command allows retrieval of system status indicators. Each --- 1387,1393 command, which has the form: ! GET CURRENT DIAGNOSTICS variable = item , ... ; This command allows retrieval of system status indicators. Each *** *** 1488,1493 --- 1488,1580 + + Obtaining the Exception Status + + + Inside an exception handler, one may retrieve detailed + information about the current exception using THE + GET STACKED DIAGNOSTICS command, which has the form: + + + GET STACKED DIAGNOSTICS variable = item , ... ; + + + + + This command allows retrieval of the exception's data. Each + item is a key word identifying a state + value to be assigned to the specified variable (which should be + of the right data type to receive it). The currently available + status items are: + + + Stacked diagnostics values + + + + Name + Return type + Description + + + + + RETURNED_SQLSTATE + text + the SQLSTATE of the exception + + + MESSAGE_TEXT + text + the text of the exception's message + + + PG_EXCEPTION_DETAIL + text + the text of the exception's detail message + + + PG_EXCEPTION_HINT + text + the text of the exception's hint message + + + PG_EXCEPTION_CONTEXT + text + lines of text describing the call stack + + + + + + + + If an exception does not contain a value for an item, an empty string + will be returned. + + + + An example: + + DECLARE + text_var1 text; + text_var2 text; + text_var3 text; + BEGIN + -- some processing which might cause an exception + ... + EXCEPTION WHEN OTHERS THEN + GET STACKED DIAGNOSTICS text_var1 = MESSAGE_TEXT, + text_var2 = PG_EXCEPTION_DETAIL, + text_var3 = PG_EXCEPTION_HINT; + END; + + + + + + Doing Nothing At All *** ./src/backend/utils/errcodes.txt.orig 2011-07-15 07:53:03.070787661 +0200 --- ./src/backend/utils/errcodes.txt 2011-07-15 08:01:04.522609180 +0200 *** *** 132,137 --- 132,140 0P000EERRCODE_INVALID_ROLE_SPECIFICATION invalid_role_specification + Section: Class 0Z - Diagnostics Exception + 0Z002EERRCODE_STACKED_DIAGNOSTICS_ACCESSED_WITHOUT_ACTIVE_HANDLERstacked_diagnostics_accessed_without_active_handler + Section: Class 20 - Case Not Found 2EERRCODE_CASE_NOT_FOUND case_not_found *** ./src/pl/plpgsql/src/gram.y.orig 2011-07-15 07:53:03.071787651 +0200 --- ./src/pl/plpgsql/src/gram.y 2011-07-15 09:29:27.959407772 +0200 *** *** 206,211 --- 206,212 %type getdiag_list %type getdiag_list_item %type getdiag_item getdiag_target + %type getdiag_opt %type opt_scrollable %type opt_fetch_direction *** *** 250,256 --- 251,259 %token K_CLOSE %token K_COLLATE %token K_CONSTANT + %token K_CONTEXT %token K_CONTINUE + %token K_CURRENT %token K_CURSOR %token K_DEBUG %token K_DECLARE *** *** 263,268 --- 266,274 %token K_END %token K_ERRCODE %token K_ERROR + %token K_EXCEPTION_CONTEXT + %token K_EXCEPTION_DETAIL + %token K_EXCEPTION_HINT %token K_EXCEPTION %token K_EXECUTE %token K_EXIT *** *** 284,289 --- 290,296 %token K_LOG %token K_LOOP %token K_MESSAGE + %token K_MESSAGE_TEXT %token K_MOVE %token K_NEXT %token K_NO *** *** 300,311 --- 307,320 %token K_RELATIVE %token K_RESULT_OID %token K_RETURN + %token K_RETURNED_SQLSTATE %token K_REVERSE %token K_ROWTYPE %token K_ROW_COUNT %token K_SCROLL %token K_SLICE %token K_SQLSTATE + %token K_STACKED %token K_STRICT %token K_THEN %token K_TO ***
Re: [HACKERS] patch: enhanced get diagnostics statement 2
2011/7/14 Alvaro Herrera : > Excerpts from Pavel Stehule's message of jue jul 14 16:25:56 -0400 2011: >> 2011/7/14 Alvaro Herrera : >> > A couple items for this patch: > >> it is good idea > > Thanks ... I expect you're going to resubmit the patch based on David's > last version and my comments? > yes, but tomorrow, time to go sleep Regards Pavel > -- > Álvaro Herrera > The PostgreSQL Company - Command Prompt, Inc. > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: enhanced get diagnostics statement 2
Excerpts from Pavel Stehule's message of jue jul 14 16:25:56 -0400 2011: > 2011/7/14 Alvaro Herrera : > > A couple items for this patch: > it is good idea Thanks ... I expect you're going to resubmit the patch based on David's last version and my comments? -- Álvaro Herrera The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: enhanced get diagnostics statement 2
2011/7/14 Alvaro Herrera :
> A couple items for this patch:
>
> The docs state that the variable to receive each diagnostic value needs
> to be "of the right data type" but fails to specify what it is. I think
> it'd be good to turn that into a table with three
> columns: name, type, description.
>
> This seems poor style:
>
> + case PLPGSQL_GETDIAG_ERROR_CONTEXT:
> + case PLPGSQL_GETDIAG_ERROR_DETAIL:
> + case PLPGSQL_GETDIAG_ERROR_HINT:
> + case PLPGSQL_GETDIAG_RETURNED_SQLSTATE:
> + case PLPGSQL_GETDIAG_MESSAGE_TEXT:
> + if (!$2)
> + ereport(ERROR,
> + (errcode(ERRCODE_SYNTAX_ERROR),
> + errmsg("EXCEPTION_CONTEXT or
> EXCEPTION_DETAIL or EXCEPTION_HINT or RETURNED_SQLSTATE or MESSAGE_TEXT are
> not allowed in current diagnostics statement"),
> + parser_errposition(@1)));
> +
>
>
> I think we could replace this with something like
>
> + if (!$2)
> + ereport(ERROR,
> + (errcode(ERRCODE_SYNTAX_ERROR),
> + errmsg("diagnostic value %s is
> not allowed in GET CURRENT DIAGNOSTICS statement", stringify(ditem->kind)),
>
>
> Other than that, and a few grammar fixes in code comments, this seems
> good to me.
>
it is good idea
Regards
Pavel
> --
> Álvaro Herrera
> The PostgreSQL Company - Command Prompt, Inc.
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: enhanced get diagnostics statement 2
A couple items for this patch:
The docs state that the variable to receive each diagnostic value needs
to be "of the right data type" but fails to specify what it is. I think
it'd be good to turn that into a table with three
columns: name, type, description.
This seems poor style:
+ case PLPGSQL_GETDIAG_ERROR_CONTEXT:
+ case PLPGSQL_GETDIAG_ERROR_DETAIL:
+ case PLPGSQL_GETDIAG_ERROR_HINT:
+ case PLPGSQL_GETDIAG_RETURNED_SQLSTATE:
+ case PLPGSQL_GETDIAG_MESSAGE_TEXT:
+ if (!$2)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+errmsg("EXCEPTION_CONTEXT or
EXCEPTION_DETAIL or EXCEPTION_HINT or RETURNED_SQLSTATE or MESSAGE_TEXT are not
allowed in current diagnostics statement"),
+parser_errposition(@1)));
+
I think we could replace this with something like
+ if (!$2)
+ ereport(ERROR,
+ (errcode(ERRCODE_SYNTAX_ERROR),
+errmsg("diagnostic value %s is not
allowed in GET CURRENT DIAGNOSTICS statement", stringify(ditem->kind)),
Other than that, and a few grammar fixes in code comments, this seems
good to me.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: enhanced get diagnostics statement 2
On Jul 7, 2011, at 12:30 AM, Pavel Stehule wrote: > thank you very much for review. I thank you, too, Hanada-san. I was assigned to review this patch, but you beat me to it. So now I'll do the follow-up review. > I cleaned patch and merged your documentation patch > > I hope, this is all - a language correction should do some native speaker Contents & Purpose == The patch extends the `GET DIAGNOSTICS` syntax to accept new two new keywords, `CURRENT` and `STACKED`, which are described in the SQL/PSM standard. This feature allows one to retrieve exception information in an `EXCEPTION` block. The patch also adds three PostgreSQL-specific fields: * `PG_EXCEPTION_DETAIL` contains the exception detail message * `PG_EXCEPTION_HINT` contains the exception hint, if any * `PG_EXCEPTION_CONTEXT` contains lines that describes call stack Submission Review = The patch is a unified diff, and applies cleanly to master at 89fd72cb. The regression tests all pass successfully against the new patch, so the test cases are sane and do cover the new behavior. The patch includes regression tests which appear to adequately cover the proposed functionality. They also contain documentation, although the wording, while understandable, needs the attention of a native speaker. I've taken it upon myself to make some revisions, including moving the list of fields into a list. I've attached a new patch with these changes below. Usability review * I agree that it's useful to get detailed information inside EXCEPTION clause. * We don't have this feature yet. * This patch follows SQL spec of GET DIAGNOSTICS, and extends about PG-specific variables. * pg_dump support is not required for this feature. * AFAICS, this patch doesn't have any danger, such as breakage of backward compatibility, thanks to the new `STACKED` keyword. I suppose there could be a conflict if someone had a variable named STACKED in the function, but I doubt it, given the context in which it's used. Feature test * The new feature introduced by the patch works well. I ran some basic tests and it worked very nicely. I'm excited to get this functionality! Conclusion == Attached is a new patch with my documentation changes (and in context diff format). The code looks clean and unobtrusive, the functionality it adds is useful, and overall I'd say it's ready for committer. Best, David stacked_diagnostics_3.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch: enhanced get diagnostics statement 2
Hello thank you very much for review. I cleaned patch and merged your documentation patch I hope, this is all - a language correction should do some native speaker Regards Pavel Stehule 2011/7/6 Shigeru Hanada : > (2011/06/02 17:39), Pavel Stehule wrote: >> This patch enhances a GET DIAGNOSTICS statement functionality. It adds >> a possibility of access to exception's data. These data are stored on >> stack when exception's handler is activated - and these data are >> access-able everywhere inside handler. It has a different behave (the >> content is immutable inside handler) and therefore it has modified >> syntax (use keyword STACKED). This implementation is in conformance >> with ANSI SQL and SQL/PSM - implemented two standard fields - >> RETURNED_SQLSTATE and MESSAGE_TEXT and three PostgreSQL specific >> fields - PG_EXCEPTION_DETAIL, PG_EXCEPTION_HINT and >> PG_EXCEPTION_CONTEXT. >> >> The GET STACKED DIAGNOSTICS statement is allowed only inside >> exception's handler. When it is used outside handler, then diagnostics >> exception 0Z002 is raised. >> >> This patch has no impact on performance. It is just interface to >> existing stacked 'edata' structure. This patch doesn't change a >> current behave of GET DIAGNOSTICS statement. >> >> CREATE OR REPLACE FUNCTION public.stacked_diagnostics_test02() >> RETURNS void >> LANGUAGE plpgsql >> AS $function$ >> declare _detail text; _hint text; _message text; >> begin >> perform ... >> exception when others then >> get stacked diagnostics >> _message = message_text, >> _detail = pg_exception_detail, >> _hint = pg_exception_hint; >> raise notice 'message: %, detail: %, hint: %', _message, _detail, _hint; >> end; >> $function$ >> >> All regress tests was passed. > > Hi Pavel, > > I've reviewed your patch according to the page "Reviewing a patch". > During the review, I referred to Working-Draft of SQL 2003 to confirm > the SQL specs. > > Submission review > = > * The patch is in context diff format. > * The patch couldn't be applied cleanly to the current head. But it > requires only one hunk to be offset, and it could be fixed easily. > I noticed that new variables needs_xxx, which were added to struct > PLpgSQL_condition, are not used at all. They should be removed, or > something might be overlooked. > * The patch includes reasonable regression tests. The patch also > includes hunks for pl/pgsql document which describes new > feature. But it would need some corrections: > - folding too-long lines > - fixing some grammatical errors (maybe) > - clarify difference between CURRENT and STACKED > I think that adding new section for GET STACKED DIAGNOSTICS would help > to clarify the difference, because the keyword STACKED can be used only > in exception clause, and available information is different from the one > available for GET CURRENT DIAGNOSTICS. Please find attached a patch > which includes a proposal for document though it still needs review by > English speaker. > > Usability review > > * The patch extends GET DIAGNOSTICS syntax to accept new keywords > CURRENT and STACKED, which are described in the SQL/PSM standard. This > feature allows us to retrieve exception information in EXCEPTION clause. > Naming of PG-specific fields might be debatable. > * I think it's useful to get detailed information inside EXCEPTION clause. > * We don't have this feature yet. > * This patch follows SQL spec of GET DIAGNOSTICS, and extends about > PG-specific variables. > * pg_dump support is not required for this feature. > * AFAICS, this patch doesn't have any danger, such as breakage of > backward compatibility. > > Feature test > > * The new feature introduced by the patch works well. > I tested about: > - CURRENT doesn't affect existing feature > - STACKED couldn't be used outside EXCEPTION clause > - Values could be retrieved via RETURNED_SQLSTATE, MESSAGE_TEXT, > PG_EXCEPTION_DETAIL, PG_EXCEPTION_HINT and PG_EXCEPTION_CONTEXT > - Invalid item names properly cause error. > * I'm not so familiar to pl/pgsql, but ISTM that enough cases are > considered about newly added diagnostics items. > * I didn't see any crash during my tests. > > In conclusion, this patch still needs some effort to be "Ready for > Committer", so I'll push it back to "Waiting on Author". > > Regards, > -- > Shigeru Hanada > *** ./doc/src/sgml/plpgsql.sgml.orig 2011-07-07 09:03:07.135669770 +0200 --- ./doc/src/sgml/plpgsql.sgml 2011-07-07 09:12:20.443762372 +0200 *** *** 1387,1393 command, which has the form: ! GET DIAGNOSTICS variable = item , ... ; This command allows retrieval of system status indicators. Each --- 1387,1393 command, which has the form: ! GET CURRENT DIAGNOSTICS variable = item , ... ; This command allows retrieval of system status indicators. Each *** *** 1488,1493 --- 1488,1535 -
Re: [HACKERS] patch: enhanced get diagnostics statement 2
(2011/06/02 17:39), Pavel Stehule wrote:
> This patch enhances a GET DIAGNOSTICS statement functionality. It adds
> a possibility of access to exception's data. These data are stored on
> stack when exception's handler is activated - and these data are
> access-able everywhere inside handler. It has a different behave (the
> content is immutable inside handler) and therefore it has modified
> syntax (use keyword STACKED). This implementation is in conformance
> with ANSI SQL and SQL/PSM - implemented two standard fields -
> RETURNED_SQLSTATE and MESSAGE_TEXT and three PostgreSQL specific
> fields - PG_EXCEPTION_DETAIL, PG_EXCEPTION_HINT and
> PG_EXCEPTION_CONTEXT.
>
> The GET STACKED DIAGNOSTICS statement is allowed only inside
> exception's handler. When it is used outside handler, then diagnostics
> exception 0Z002 is raised.
>
> This patch has no impact on performance. It is just interface to
> existing stacked 'edata' structure. This patch doesn't change a
> current behave of GET DIAGNOSTICS statement.
>
> CREATE OR REPLACE FUNCTION public.stacked_diagnostics_test02()
> RETURNS void
> LANGUAGE plpgsql
> AS $function$
> declare _detail text; _hint text; _message text;
> begin
>perform ...
> exception when others then
>get stacked diagnostics
> _message = message_text,
> _detail = pg_exception_detail,
> _hint = pg_exception_hint;
>raise notice 'message: %, detail: %, hint: %', _message, _detail, _hint;
> end;
> $function$
>
> All regress tests was passed.
Hi Pavel,
I've reviewed your patch according to the page "Reviewing a patch".
During the review, I referred to Working-Draft of SQL 2003 to confirm
the SQL specs.
Submission review
=
* The patch is in context diff format.
* The patch couldn't be applied cleanly to the current head. But it
requires only one hunk to be offset, and it could be fixed easily.
I noticed that new variables needs_xxx, which were added to struct
PLpgSQL_condition, are not used at all. They should be removed, or
something might be overlooked.
* The patch includes reasonable regression tests. The patch also
includes hunks for pl/pgsql document which describes new
feature. But it would need some corrections:
- folding too-long lines
- fixing some grammatical errors (maybe)
- clarify difference between CURRENT and STACKED
I think that adding new section for GET STACKED DIAGNOSTICS would help
to clarify the difference, because the keyword STACKED can be used only
in exception clause, and available information is different from the one
available for GET CURRENT DIAGNOSTICS. Please find attached a patch
which includes a proposal for document though it still needs review by
English speaker.
Usability review
* The patch extends GET DIAGNOSTICS syntax to accept new keywords
CURRENT and STACKED, which are described in the SQL/PSM standard. This
feature allows us to retrieve exception information in EXCEPTION clause.
Naming of PG-specific fields might be debatable.
* I think it's useful to get detailed information inside EXCEPTION clause.
* We don't have this feature yet.
* This patch follows SQL spec of GET DIAGNOSTICS, and extends about
PG-specific variables.
* pg_dump support is not required for this feature.
* AFAICS, this patch doesn't have any danger, such as breakage of
backward compatibility.
Feature test
* The new feature introduced by the patch works well.
I tested about:
- CURRENT doesn't affect existing feature
- STACKED couldn't be used outside EXCEPTION clause
- Values could be retrieved via RETURNED_SQLSTATE, MESSAGE_TEXT,
PG_EXCEPTION_DETAIL, PG_EXCEPTION_HINT and PG_EXCEPTION_CONTEXT
- Invalid item names properly cause error.
* I'm not so familiar to pl/pgsql, but ISTM that enough cases are
considered about newly added diagnostics items.
* I didn't see any crash during my tests.
In conclusion, this patch still needs some effort to be "Ready for
Committer", so I'll push it back to "Waiting on Author".
Regards,
--
Shigeru Hanada
diff --git a/doc/src/sgml/plpgsql.sgml b/doc/src/sgml/plpgsql.sgml
index 3d07b6e..7df69a7 100644
*** a/doc/src/sgml/plpgsql.sgml
--- b/doc/src/sgml/plpgsql.sgml
*** EXECUTE format('UPDATE tbl SET %I = $1 W
*** 1387,1393
command, which has the form:
! GET CURRENT | STACKED DIAGNOSTICS
variable = item
, ... ;
This command allows retrieval of system status indicators. Each
--- 1387,1393
command, which has the form:
! GET CURRENT DIAGNOSTICS
variable = item
, ... ;
This command allows retrieval of system status indicators. Each
*** GET DIAGNOSTICS integer_var = ROW_COUNT;
*** 1486,1506
affect only the current function.
! Inside a exception handler is possible to use a stacked diagnostics
statement. It
! allows a access to exception's data: the
RETURNED_SQLSTATE contains
! a SQLSTATE of
[HACKERS] patch: enhanced get diagnostics statement 2
Hello This patch enhances a GET DIAGNOSTICS statement functionality. It adds a possibility of access to exception's data. These data are stored on stack when exception's handler is activated - and these data are access-able everywhere inside handler. It has a different behave (the content is immutable inside handler) and therefore it has modified syntax (use keyword STACKED). This implementation is in conformance with ANSI SQL and SQL/PSM - implemented two standard fields - RETURNED_SQLSTATE and MESSAGE_TEXT and three PostgreSQL specific fields - PG_EXCEPTION_DETAIL, PG_EXCEPTION_HINT and PG_EXCEPTION_CONTEXT. The GET STACKED DIAGNOSTICS statement is allowed only inside exception's handler. When it is used outside handler, then diagnostics exception 0Z002 is raised. This patch has no impact on performance. It is just interface to existing stacked 'edata' structure. This patch doesn't change a current behave of GET DIAGNOSTICS statement. CREATE OR REPLACE FUNCTION public.stacked_diagnostics_test02() RETURNS void LANGUAGE plpgsql AS $function$ declare _detail text; _hint text; _message text; begin perform ... exception when others then get stacked diagnostics _message = message_text, _detail = pg_exception_detail, _hint = pg_exception_hint; raise notice 'message: %, detail: %, hint: %', _message, _detail, _hint; end; $function$ All regress tests was passed. Regards Pavel Stehule *** ./doc/src/sgml/plpgsql.sgml.orig 2011-05-18 14:22:28.0 +0200 --- ./doc/src/sgml/plpgsql.sgml 2011-06-02 09:43:49.682013158 +0200 *** *** 1387,1393 command, which has the form: ! GET DIAGNOSTICS variable = item , ... ; This command allows retrieval of system status indicators. Each --- 1387,1393 command, which has the form: ! GET CURRENT | STACKED DIAGNOSTICS variable = item , ... ; This command allows retrieval of system status indicators. Each *** *** 1486,1491 --- 1486,1516 affect only the current function. + + Inside a exception handler is possible to use a stacked diagnostics statement. It + allows a access to exception's data: the RETURNED_SQLSTATE contains + a SQLSTATE of handled exception. MESSAGE_TEXT contains a message text, + PG_EXCEPTION_DETAIL has a text that is shown as exception detail, + PG_EXCEPTION_HINT has a hint related to catched exception. + PG_EXCEPTION_CONTEXT contains a lines that describes call stack. These + variables holds a text value. When some field of exception are not filled, then related + variable contains a empty string, + + + + An example: + + BEGIN + ... + EXCEPTION WHEN OTHERS THEN + GET STACKED DIAGNOSTICS text_var1 = MESSAGE_TEXT, + text_var2 = PG_EXCEPTION_DETAIL, + text_var3 = PG_EXCEPTION_HINT; + END; + + + + *** ./src/backend/utils/errcodes.txt.orig 2011-05-18 14:22:29.0 +0200 --- ./src/backend/utils/errcodes.txt 2011-06-01 20:43:16.128831780 +0200 *** *** 132,137 --- 132,141 0P000EERRCODE_INVALID_ROLE_SPECIFICATION invalid_role_specification + Section: Class 0Z - Diagnostics Exception + 0Z000EERRCODE_DIAGNOSTICS_EXCEPTION diagnostics_exception + 0Z002EERRCODE_STACKED_DIAGNOSTICS_ACCESSED_WITHOUT_ACTIVE_HANDLERstacked_diagnostics_accessed_without_active_handler + Section: Class 20 - Case Not Found 2EERRCODE_CASE_NOT_FOUND case_not_found *** ./src/pl/plpgsql/src/gram.y.orig 2011-05-18 19:41:56.755678378 +0200 --- ./src/pl/plpgsql/src/gram.y 2011-06-02 08:52:31.687830966 +0200 *** *** 206,211 --- 206,212 %type getdiag_list %type getdiag_list_item %type getdiag_item getdiag_target + %type getdiag_opt %type opt_scrollable %type opt_fetch_direction *** *** 250,256 --- 251,259 %token K_CLOSE %token K_COLLATE %token K_CONSTANT + %token K_CONTEXT %token K_CONTINUE + %token K_CURRENT %token K_CURSOR %token K_DEBUG %token K_DECLARE *** *** 263,268 --- 266,274 %token K_END %token K_ERRCODE %token K_ERROR + %token K_EXCEPTION_CONTEXT + %token K_EXCEPTION_DETAIL + %token K_EXCEPTION_HINT %token K_EXCEPTION %token K_EXECUTE %token K_EXIT *** *** 284,289 --- 290,296 %token K_LOG %token K_LOOP %token K_MESSAGE + %token K_MESSAGE_TEXT %token K_MOVE %token K_NEXT %token K_NO *** *** 300,311 --- 307,320 %token K_RELATIVE %token K_RESULT_OID %token K_RETURN + %token K_RETURNED_SQLSTATE %token K_REVERSE %token K_ROWTYPE %token K_ROW_COUNT %token K_SCROLL %token K_SLICE %token K_SQLSTATE + %token
