Re: alternative to PG_CATCH - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: alternative to PG_CATCH
Date
Msg-id a0d756d0-d00c-de74-97f7-0f9055058572@2ndQuadrant.com
Whole thread Raw
In response to alternative to PG_CATCH  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: alternative to PG_CATCH  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: Introducing SNI in TLS handshake for SSL connections
Next
From: David Steele
Date:
Subject: Re: Add timeline to partial WAL segments