While your message was directed at Thomas, I think I share Thomas'
position; well, for the most part.
On Tue, 2004-11-30 at 11:21 -0500, Tom Lane wrote:
> But I think it's a bogus design, because (a) it puts extra burden on the
> function author who's already got enough things to worry about, and
Simply put, IMO, a subtransaction is != an exception, and shouldn't be
treated as one.
If the author wishes to worry about transaction management that is his
worry. I don't feel the extra "burden" is significant enough to justify
hacking around in the Python interpreter(assuming that it's possible in
the first place).
Personally, I think the decision is fine for plpgsql, but not for
Python, or just about any other language. plpgsql is a special case,
IMO.
> (b) since you can't support arbitrary rollback patterns, you have to
> contort the semantics of Savepoint objects with restrictions that are
> both hard to design correctly and complicated to enforce.
Hrm, isn't this what savepoint levels are supposed to do? Impose those
restrictions?
I'm guessing Postgres doesn't have savepoint levels yet, per lack of
response to my message inquiring about them(well, a "savepoint scoping
facility"), and poking around xact.h not revealing anything either.
I think I may hold a more of a hold nose stance here than Thomas. I am
not sure if I want to implement savepoint/rollback restrictions as I
can't help but feel this is something Postgres should handle; not me or
any other PL or C Function author.
plpy being an untrusted language, I *ultimately* do not have control
over this. I can only specify things within my code. I *cannot* stop a
user from making an extension module that draws interfaces to those
routines that may rollback to a savepoint defined by the caller. (Not a
great point, as a user could also try to dereference a NULL pointer from
an extension module as well. ;)
I feel if I were to implement such restrictions/regulations it would be
analogous to a security guard trying to enforce the law, whereas a real
police officer is needed.. ;-)
--
Regards, James William Pye
