One issue is that it may break existing PLs that override Warn_restart, since the semantics of doing that will have changed a bit. We can easily fix the PLs that are in our own CVS, but what are the implications for other PLs such as PL/R and PL/SH? Joe, Peter, any comments?
I am somewhat tempted to rename the setjmp variable Warn_restart to something else, so as to catch any code that is still expecting the old behavior (besides, it was never a very good name anyway). On the other hand, there may be cases where a PL's code doesn't actually need to change, and if so a rename would just break it unnecessarily. Any votes which way to jump?
It sounds like a good plan, and I'm sure I can adjust either way. Of course it would be nice if no changes were needed on the PL side unless they are specifically being changed to take advantage of subtransactions ;-)
Probably the hardest part is to keep the PL code readable while still supporting cvs tip and 7.4 (and 7.3 for that matter). This is yet another good example why I think bundling/synchronizing PLs with the backend is a good thing.
Joe
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
