From: | Thomas Hallgren <thhal(at)mailblocks(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Error handling in plperl and pltcl |
Date: | 2004-11-21 10:22:03 |
Message-ID: | thhal-0zgR8Aifeby4J1WphqNxnYGWS5BXeVk@mailblocks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Hallgren wrote
>> I'm planning to add subtransactions too, but my approach will be to
>> use the savepoint functionality already present in the
>> java.sql.Connection interface. Perhaps the plpy implementation could
>> do something similar. This is what I'm planning to implement:
>
> In Java, safepoints are identified by an interface rather then just by
> a name. I will (invisibly) include both the name of the safepoint and
> the call level in my implementation of that interface. I will also
> have a nested "call context" where I manage safepoints created by the
> executing function. All of this will be completely hidden from the
> function developer. This will make it possible to enforce the
> following rules:
>
> 1. A Safepoint lifecycle must be confined to a function call.
> 2. Safepoints must be rolled back or released by the same function
> that sets them.
>
> Failure to comply with those rules will result in an exception (elog
> ERROR) that will be propagated all the way up.
>
> Would you consider this as safe?
>
> Regards,
> Thomas Hallgren
s/safepoint/savepoint/g
From | Date | Subject | |
---|---|---|---|
Next Message | Stefan Kaltenbrunner | 2004-11-21 10:38:05 | Re: OpenBSD/Sparc status |
Previous Message | Neil Conway | 2004-11-21 10:20:20 | Re: How to check the postgresql version |