Re: proposal: enable new error fields in plpgsql (9.4)
| От | Rushabh Lathia |
|---|---|
| Тема | Re: proposal: enable new error fields in plpgsql (9.4) |
| Дата | |
| Msg-id | CAGPqQf16bQTq_O8TVBG5HQyXGamiCLXEY5zJRqDJ6cf6VRchWQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: proposal: enable new error fields in plpgsql (9.4) (Pavel Stehule <pavel.stehule@gmail.com>) |
| Ответы |
Re: proposal: enable new error fields in plpgsql (9.4)
(Pavel Stehule <pavel.stehule@gmail.com>)
Re: proposal: enable new error fields in plpgsql (9.4) (Pavel Stehule <pavel.stehule@gmail.com>) |
| Список | pgsql-hackers |
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.stehule@gmail.com> wrote:
2013/2/1 Pavel Stehule <pavel.stehule@gmail.com>:> 2013/2/1 Peter Eisentraut <peter_e@gmx.net>:there is one stronger argument for commit this patch now. With this
>> 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
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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Jeevan ChalkeДата:
Сообщение: Re: [Review] Add SPI_gettypmod() to return a field's typemod from a TupleDesc