On Tue, Jul 1, 2014 at 11:46 AM, Rajeev rastogi <rajeev.rastogi@huawei.com> wrote: > On 30 June 2014 22:50, Pavel Stehule Wrote: >
> >I didn't find a related message. > >? > > I think there have been some confusion, the design idea were never rejected but yes there were few feedback/ concern, which I had clarified. Also some of the other concerns are already fixed in latest patch.
Simon has mentioned that exactly this idea has been rejected at
PGCon 2 years back. Please refer that in below mail:
* Why autonomous transaction should be close to functions? We can implement AT as first step and next step can be implementation of integration AT to stored procedures.
* When autonomous transaction is independent on parent transaction, then locks parent and autonomous transaction should be in conflict
I though about integration to PL/pgSQL and I don't think so close integration between autonomous transaction and procedure is optimal. More practical is design so autonomous transaction is similar to subtransaction.
Then we can simply wrote some code like
BEGIN
.. some code
WHEN OTHERS THEN
.. I would to write permanently to log
BEGIN AUTONOMOUS
INSERT INTO log VALUES(..);
WHEN OTHERS
RAISE WARNING 'Cannot to write to log ..';
RAISE EXCEPTION ' ...' forward up exception from autonomous transaction to parent transaction
END
END;
Now I am thinking so PL/SQL design of autonomous transactions is relatively limited and is not best to follow it.
Regards
Pavel
> So I wanted to have this patch in commitfest application, so that we can have a healthy discussion and rectify all the issues. > But now I see that this patch has already been moved to rejected category, which will put break on further review.
I believe ideally this patch should have been marked as
"Returned with feedback" as you already got a feedback long
