Re: try/catch macros for Postgres backend - Mailing list pgsql-hackers

From James William Pye
Subject Re: try/catch macros for Postgres backend
Date
Msg-id 20040801003545.GC20416@void.ph.cox.net
Whole thread Raw
In response to try/catch macros for Postgres backend  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: try/catch macros for Postgres backend
List pgsql-hackers
On 07/28/04:30/3, Tom Lane wrote:
> In service of the refactoring of error handling that I was talking about
> a few days ago, I'm finding that there are several places that really
> ought to catch longjmps and clean up after themselves, instead of
> expecting that whatever mess they've made will be cleaned up for them
> when control gets back to PostgresMain().  If we have functions that can
> catch errors, control might *not* go right back to PostgresMain(), and
> so throwing random cleanup actions into the sigsetjmp branch there is
> No Good.

This is wonderful news. plpy for 7.5 will be very nice. :)

> This is no big deal since pltcl and plpython already do much the same
> thing, but I'm starting to think that instead of directly hacking on
> Warn_restart, it would be good to have some macros hiding the details.
> The syntax I'm toying with is
>
> ...
>
> Does anyone have a problem with this macro syntax?  The try/catch names
> are stolen from Java, so I'm figuring they won't terribly surprise any
> modern programmer, but I'm open to different names if anyone has a
> better idea.

Sounds good, but perhaps it would be useful for some developers to have
the macro syntax broken up into smaller pieces, plpythonu does/did this in
plpython.h(gone now), and I rolled my own based on plpython's in plpy.

for example:

#define PG_EXC_DECLARE() sigjmp_buf local_sigjmp_buf
#define PG_EXC_SAVE() \     sigjmp_buf *save_exception_stack = PG_exception_stack; \     ErrorContextCallback
*save_context_stack= error_context_stack 
#define PG_EXC_TRAP() (sigsetjmp(local_sigjmp_buf, 1) == 0)
...

You could then use those to make up PG_TRY, PG_CATCH, PG_END_TRY.

Although, I'm not too concerned about this, as if someone wants the smaller
pieces they could probably just write their own without much difficulty.


> Also, the memcpy technique for saving/restoring Warn_restart is what
> pltcl and plpython currently use, and it works, but it seems
> unnecessarily inefficient.  A further improvement would be to replace
> Warn_restart by a pointer defined like
>     extern sigjmp_buf *exception_stack_top;

Aye, good idea.

--
Regards,       James William Pye

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: About pgevent
Next
From: Tom Lane
Date:
Subject: Re: Version Numbering -- The great debate