Tom Lane wrote:
On what evidence do you base that claim? It's true there are noLack of error trapping is one thing. To state that all error trapping will do further accesses to the database is another altogether. I don't have evidence for my claim since subtransactions hasn't been available for that long but it's a pretty strong hunch. And the fact that all current PostgreSQL functions out there works this way today should count for something. Your suggestion will make the current code base significantly slower, IMO for no reason.
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.
So it's an extra burden to create a savepoint, and commit/rollback depending on the outcome? I'm sorry, but I have to disagree with that. I think it's a powerful concept that developers will want to exploit. Confusing try/catch with subtransactions is bogus and not an option for me as I don't have the liberty of changing the language.[ 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
A strong argument for my design is that if I where to write similar code in the client using a the JDBC driver, this is exactly what I'd have to do. Why should code look any different just because I move it to the backend?
So, I can't see the extra burden at all. This approach brings clarity, no magic, and it enables ports of languages where SQL access has been standardized to actually conform to that standard. That's most certainly not bogus!
(b) since you can't support arbitrary rollback patterns, you have toOn the contrary. It's very easy to enforce and PL/Java already does this. The design is simple and clean. Savepoints are prohibited to live beyond the invocation where they where created. If a savepoint is still active when an invocation exits, the savepoint is released or rolled back (depending on a GUC setting) and a warning is printed.
contort the semantics of Savepoint objects with restrictions that are
both hard to design correctly and complicated to enforce.
Here I have a couple of questions to you:
From your statement it sounds like you want to use the subtransactions solely in a hidden mechanism and completely remove the ability to use them from the function developer. Is that a correct interpretation?
Another question relating to a statement you made earlier. You claim that an SPI call should check to see if it it is in a subtransaction and only enter a new one if that's not the case. How do you in that case intend to keep track of where the subtransaction started? I.e. how far up in nesting levels do you need to jump before you reach the right place?
My argument is that whenever possible, you must let the creator of a subtransaction have the responsibility to commit or roll it back.
I don't do language design. I'm adhering to the JDBC standard and I have no way of enforcing magic code to be executed during try/catch. Meanwhile, I really want PL/Java developers to have the ability to make full use of savepoints.I don't believe you should do language design on the basis of avoiding a 25% overhead
I got it down from 50% to 25%That's great. But even if you come down to 10% overhead it doesn't really change anything.
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, Thomas Hallgren
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
