"Gurjeet Singh" <[EMAIL PROTECTED]> writes: > I propose a new constuct, PG_FINALLY.
I took a look through the existing uses of PG_CATCH, and found that in the places where there is duplicate code between the normal and error exits, it's usually just one or two lines. Where it's more than that, it's intermixed with code that is not duplicate, and so PG_FINALLY wouldn't help. I don't care to add code to every use of PG_TRY for such a limited benefit. To the extent that the compiler is able to recognize and optimize out the extra code in blocks where do_re_throw is never changed, that objection loses force --- but in such cases it seems likely that some compilers would throw a warning, which we don't want. Lastly, your proposal silently breaks every existing use of PG_TRY by changing the existing semantics of PG_CATCH. That will certainly not do. (This is not even counting the bug that the CATCH code would be executed inside the same setjmp context, so that any elog within the CATCH code would turn into an infinite loop.) Possibly it'd make sense to offer PG_FINALLY as a mutually exclusive alternative to PG_CATCH, rather than trying to allow both to be used in the same TRY construct. I doubt you've got reasonable semantics for the combination anyway --- it seems at least as likely that the common actions would need to be executed before the special error actions as after. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster