"Gurjeet Singh" <singh.gurjeet@gmail.com> 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