Re: Error handling in plperl and pltcl
От | James William Pye |
---|---|
Тема | Re: Error handling in plperl and pltcl |
Дата | |
Msg-id | 1101848539.6288.71.camel@localhost обсуждение исходный текст |
Ответ на | Re: Error handling in plperl and pltcl (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Error handling in plperl and pltcl
Re: Error handling in plperl and pltcl |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: