| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgreSQL(dot)org |
| Subject: | Re: Sketch of extending error handling for subtransactions in functions |
| Date: | 2004-07-25 01:45:51 |
| Message-ID: | 410310CF.7050507@joeconway.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> One issue is that it may break existing PLs that override Warn_restart,
> since the semantics of doing that will have changed a bit. We can
> easily fix the PLs that are in our own CVS, but what are the
> implications for other PLs such as PL/R and PL/SH? Joe, Peter, any
> comments?
> I am somewhat tempted to rename the setjmp variable Warn_restart to
> something else, so as to catch any code that is still expecting the
> old behavior (besides, it was never a very good name anyway). On the
> other hand, there may be cases where a PL's code doesn't actually need
> to change, and if so a rename would just break it unnecessarily. Any
> votes which way to jump?
It sounds like a good plan, and I'm sure I can adjust either way. Of
course it would be nice if no changes were needed on the PL side unless
they are specifically being changed to take advantage of subtransactions ;-)
Probably the hardest part is to keep the PL code readable while still
supporting cvs tip and 7.4 (and 7.3 for that matter). This is yet
another good example why I think bundling/synchronizing PLs with the
backend is a good thing.
Joe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-07-25 02:33:55 | Re: Sketch of extending error handling for subtransactions |
| Previous Message | Bruce Momjian | 2004-07-25 01:20:43 | Re: Sketch of extending error handling for subtransactions |