Re: proposal: enable new error fields in plpgsql (9.4)
От | Pavel Stehule |
---|---|
Тема | Re: proposal: enable new error fields in plpgsql (9.4) |
Дата | |
Msg-id | CAFj8pRDz9is9VKBoycV9TiRW_r9No2M_3zmTQFZcjWobVmbJzg@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)
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: