Re: alternative to PG_CATCH
От | Peter Eisentraut |
---|---|
Тема | Re: alternative to PG_CATCH |
Дата | |
Msg-id | 4d82d8ae-30f1-b8d1-fe21-b08924c1cb39@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: alternative to PG_CATCH (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: alternative to PG_CATCH
|
Список | pgsql-hackers |
On 13/12/2018 13:26, Kyotaro HORIGUCHI wrote: > Though I didn't look into individual change, this kind of > refactoring looks good to me. But the syntax looks > somewhat.. uh.. > > I'm not sure it is actually workable, but I suspect that what we > need here is just a shortcut of 'PG_CATCH();{PG_RE_THROW();}'. > Something like this: > > #define PG_FINALLY() \ > } \ > else \ > { \ > PG_exception_stack = save_exception_stack; \ > error_context_stack = save_context_stack; \ > PG_RE_THROW(); \ > } \ > PG_exception_stack = save_exception_stack; \ > error_context_stack = save_context_stack; \ > { I don't think this works, because the "finally" code needs to be run in the else branch before the rethrow. The fundamental problem, as I see it, is that the macro expansion needs to produce the "finally" code twice: Once in the else (error) branch of the setjmp, and once in the non-error code path, either after the if-setjmp, or in the try block. But to be able to do that, we need to capture the block as a macro argument. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: