Re: Error handling in plperl and pltcl
От | Tom Lane |
---|---|
Тема | Re: Error handling in plperl and pltcl |
Дата | |
Msg-id | 20942.1101831676@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Error handling in plperl and pltcl (Thomas Hallgren <thhal@mailblocks.com>) |
Ответы |
Re: Error handling in plperl and pltcl
Re: Error handling in plperl and pltcl |
Список | pgsql-hackers |
Thomas Hallgren <thhal@mailblocks.com> writes: > I don't understand this either. Why a subtransaction at all? > Don't get me wrong. I fully understand that a subtransaction would make > error recovery possible. What I try to say is that the kind of error > recovery that needs a subtransaction is fairly, or perhaps even very, rare. On what evidence do you base that claim? It's true there are no existing Tcl or Perl functions that do error recovery from SPI operations, because it doesn't work in existing releases. That does not mean the demand is not there. We certainly got beat up on often enough about the lack of error trapping in plpgsql. > or I can write: > Savepoint sp = myConn->setSavepoint("foo"); > try > { > // do something > sp.commit(); > } > catch(SQLException e) > { > sp.rollback(); > // Handle error and continue execution. > } [ shrug... ] If you intend to design pljava that way I can't stop you. But I think it's a bogus design, because (a) it puts extra burden on the function author who's already got enough things to worry about, and (b) since you can't support arbitrary rollback patterns, you have to contort the semantics of Savepoint objects with restrictions that are both hard to design correctly and complicated to enforce. I don't believe you should do language design on the basis of avoiding a 25% overhead, especially not when there's every reason to think that number can be reduced in future releases. I got it down from 50% to 25% in one afternoon, doing nothing that seemed too risky for late beta. I think there's plenty more that can be done there when we have more time to work on it. regards, tom lane
В списке pgsql-hackers по дате отправления: