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

2013/6/25 Rushabh Lathia <rushabh.lathia@gmail.com>:
> 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.

No, these fields are there as was proposed - it enhance possibilities
to PLpgSQL developers - they can use these fields for custom
exceptions. It is same like possibility to specify SQLCODE, MESSAGE,
HINT in current RAISE statement implementation.

Why you dislike it?

Regards

Pavel

>
> Apart from that patch looks good to me.
>
> Thanks,
> Rushabh
>
>
> On Fri, Feb 1, 2013 at 7:29 PM, Pavel Stehule <pavel.stehule@gmail.com>
> wrote:
>>
>> 2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>:
>> > 2013/2/1 Peter Eisentraut <peter_e@gmx.net>:
>> >> On 2/1/13 8:00 AM, Pavel Stehule wrote:
>> >>> 2013/2/1 Marko Tiikkaja <pgmail@joh.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@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>
>
>
>
> --
> Rushabh Lathia