Re: proposal: enable new error fields in plpgsql (9.4) - Mailing list pgsql-hackers
From | Rushabh Lathia |
---|---|
Subject | Re: proposal: enable new error fields in plpgsql (9.4) |
Date | |
Msg-id | CAGPqQf2hgqNtf8BENNA1SC7KVOAR-7T8GXq6iG_1tFL9ws7Wzg@mail.gmail.com Whole thread Raw |
In response to | Re: proposal: enable new error fields in plpgsql (9.4) (Pavel Stehule <pavel.stehule@gmail.com>) |
Responses |
Re: proposal: enable new error fields in plpgsql (9.4)
|
List | pgsql-hackers |
On Tue, Jun 25, 2013 at 2:41 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
2013/6/25 Rushabh Lathia <rushabh.lathia@gmail.com>:No, these fields are there as was proposed - it enhance possibilities> 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.
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?
Seems like some confusion.
I noticed additional new line which has been added into your patch in function
read_raise_options()::pl_gram.y @ line number 3680. And in the earlier mail
thats what I asked to remove.
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
Rushabh Lathia
pgsql-hackers by date: