Re: proposal: enable new error fields in plpgsql (9.4)

Hi Pavel,

I gone through the discussion over here and found that with this patch we
enable the new error fields in plpgsql. Its a simple patch to expose the new
error fields in plpgsql.

Patch gets applied cleanly. make and make install too went smooth. make
check
was smooth too. Patch also include test coverage

I tested the functionality with manual test and its woking as expected.

BTW in the patch I found one additional new like in read_raise_options():

@@ -3631,7 +3661,23 @@ read_raise_options(void)
else if (tok_is_keyword(tok, &yylval,
K_HINT,
"hint"))
opt->opt_type = PLPGSQL_RAISEOPTION_HINT;
+ else if (tok_is_keyword(tok, &yylval,
+
K_COLUMN_NAME, "column_name"))
+ opt->opt_type = PLPGSQL_RAISEOPTION_COLUMN_NAME;
+ else if (tok_is_keyword(tok, &yylval,
+
K_CONSTRAINT_NAME, "constraint_name"))
+ opt->opt_type = PLPGSQL_RAISEOPTION_CONSTRAINT_NAME;
+ else if (tok_is_keyword(tok, &yylval,
+
K_DATATYPE_NAME, "datatype_name"))
+ opt->opt_type = PLPGSQL_RAISEOPTION_DATATYPE_NAME;
+ else if (tok_is_keyword(tok, &yylval,
+
K_TABLE_NAME, "table_name"))
+ opt->opt_type = PLPGSQL_RAISEOPTION_TABLE_NAME;
+ else if (tok_is_keyword(tok, &yylval,
+
K_SCHEMA_NAME, "schema_name"))
+ opt->opt_type = PLPGSQL_RAISEOPTION_SCHEMA_NAME;
else
+
yyerror("unrecognized RAISE statement option");

can you please remove that.

Apart from that patch looks good to me.

Thanks,
Rushabh

On Fri, Feb 1, 2013 at 7:29 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>wrote:

> 2013/2/1 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> > 2013/2/1 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> >> On 2/1/13 8:00 AM, Pavel Stehule wrote:
> >>> 2013/2/1 Marko Tiikkaja <pgmail(at)joh(dot)to>:
> >>>> On 2/1/13 1:47 PM, Pavel Stehule wrote:
> >>>>>
> >>>>> now a most "hard" work is done and I would to enable access to new
> >>>>> error fields from plpgsql.
> >>>>
> >>>>
> >>>> Is there a compelling reason why we wouldn't provide these already in
> 9.3?
> >>>
> >>> a time for assign to last commitfest is out.
> >>>
> >>> this patch is relative simple and really close to enhanced error
> >>> fields feature - but depends if some from commiters will have a time
> >>> for commit to 9.3 - so I am expecting primary target 9.4, but I am not
> >>> be angry if it will be commited early.
> >>
> >> If we don't have access to those fields on PL/pgSQL, what was the point
> >> of the patch to begin with? Surely, accessing them from C wasn't the
> >> main use case?
> >>
> >
> > These fields are available for application developers now. But is a
> > true, so without this patch, GET STACKED DIAGNOSTICS statement will
> > not be fully consistent, because some fields are accessible and others
> > not
>
> there is one stronger argument for commit this patch now. With this
> patch, we are able to wrote regression tests for new fields via
> plpgsql.
>
> Regards
>
> Pavel
>
> >
> > Pavel
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

--
Rushabh Lathia