Re: try/catch macros for Postgres backend

From: James William Pye <flaw(at)rhid(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: try/catch macros for Postgres backend
Date: 2004-08-01 00:35:46
Message-ID: 20040801003545.GC20416@void.ph.cox.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-08-01 00:39:22 Re: Version Numbering -- The great debate
Previous Message Tom Lane 2004-08-01 00:24:58 Re: About pgevent