Re: alternative to PG_CATCH
| От | Andrew Dunstan |
|---|---|
| Тема | Re: alternative to PG_CATCH |
| Дата | |
| Msg-id | a0d756d0-d00c-de74-97f7-0f9055058572@2ndQuadrant.com обсуждение исходный текст |
| Ответ на | alternative to PG_CATCH (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
| Ответы |
Re: alternative to PG_CATCH
|
| Список | pgsql-hackers |
On 12/13/18 5:33 AM, Peter Eisentraut wrote:
> This is a common pattern:
>
> PG_TRY();
> {
> ... code that might throw ereport(ERROR) ...
> }
> PG_CATCH();
> {
> cleanup();
> PG_RE_THROW();
> }
> PG_END_TRY();
> cleanup(); /* the same as above */
>
> I've played with a way to express this more compactly:
>
> PG_TRY();
> {
> ... code that might throw ereport(ERROR) ...
> }
> PG_FINALLY({
> cleanup();
> });
>
> See attached patch for how this works out in practice.
>
> Thoughts? Other ideas?
>
> One problem is that this currently makes pgindent crash. That's
> probably worth fixing anyway. Or perhaps find a way to write this
> differently.
>
The pgindent issue isn't at all surprising. If we wanted to fix it the
way would be to get the perl script to rewrite it with something indent
would accept (e.g. move the block outside the parentheses) and then undo
that after the indent had run.
But the block inside parentheses feels kinda funny, doesn't it?
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: