Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
От | Matt Miller |
---|---|
Тема | Re: PL/pgSQL: EXCEPTION NOSAVEPOINT |
Дата | |
Msg-id | 1125615518.3636.71.camel@dbamm01-linux обсуждение исходный текст |
Ответ на | Re: PL/pgSQL: EXCEPTION NOSAVEPOINT (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PL/pgSQL: EXCEPTION NOSAVEPOINT
Re: PL/pgSQL: EXCEPTION NOSAVEPOINT Re: PL/pgSQL: EXCEPTION NOSAVEPOINT |
Список | pgsql-hackers |
On Thu, 2005-09-01 at 18:28 -0400, Tom Lane wrote: > Matt Miller <mattm@epx.com> writes: > > Basically I'd like my Pl/pgSQL code to be able to utilize the try/catch > > paradigm of error handling without the overhead of subtransactions > > [Pl/pgSQL] can't even do 2+2 without > calling the main executor --- and recovering from elog(ERROR) without a > transaction rollback is not part of the executor's contract. Okay, so that's the crux regarding PL/pgSQL. > You might take a look at the other PLs such as plperl That would defeat my goal of not rewriting all my Oracle code. If I were fool enough to plan an attack on the main executor's exception handling to try and disarm it of its subtransaction semantics, where would I start? Where would I end? What would I do in between? Can New Orleans be rebuilt above sea level? Seriously, though, I'm willing to devote considerable time to this. Rewriting all my Oracle code function-by-function could be painful, and I would end up dragging other people around this company into it. I'm still trying to hold on to my fantasy that I can hack Postgres (and contrib/ora2pg) into submission. In the end I'm hoping that the move from Oracle will be made easier for others.
В списке pgsql-hackers по дате отправления: