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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: Where to save data used by extension ?
Следующее
От: Sergei Kornilov
Дата:
Сообщение: Re: allow online change primary_conninfo