Bradley McLean <brad@bradm.net> writes:
> Okay, the attached patch contains the following:
I have checked over and applied this patch.
It appeared that you incorporated the earlier version of Kevin's patch
rather than the later one. I made the further changes indicated by the
attached diff, which I think are all the differences between Kevin's
two submissions, but I'd appreciate it if both of you would review
what's now in CVS and confirm it's okay. (There'll probably be a beta3
release later today, so you can look at that if it's easier than CVS.)
One thing I noticed while running the selftest on a LinuxPPC box is
that the "feature" test output differed:
--- feature.expected Fri May 25 11:48:33 2001
+++ feature.output Fri Nov 16 13:00:15 2001
@@ -29,7 +29,7 @@(1 row)SELECT import_fail();
-NOTICE: ('import socket failed -- untrusted dynamic module: _socket',)
+NOTICE: ('import socket failed -- untrusted dynamic module: socket',) import_fail -------------------- failed
asexpected
I assume you guys both get the "expected" output? Perhaps this should
be noted as a possible platform discrepancy.
> Tom's requirement that we always reraise the longjmp is at odds with
> the original design of plpython, which attempted to allow a plpython
> function to use Python's exception handling to recover when an
> embedded SPI call failed. There is no way to do this that I can
> see without halting the propogation of the longjmp.
> Thus, the semantics of 'execute' calls from plpython have been changed:
> should the backend throw an error, the plpython function will be
> summarily aborted. Previously, it could attempt to catch a python
> exception.
> Note that this does create some redundant exception handling paths
> in upper level methods within this module that are no longer used.
> I have not yet removed them, but will happily do so (in a careful
> deliberate manner) once sure that there is no alternative way to
> restore the python level exception handling.
I would suggest leaving it as-is for now. Sooner or later we will
probably try to reduce the severity of most errors, and at that
point it'd become worthwhile to re-enable error trapping in plpython.
regards, tom lane
*** plpython.c~ Fri Nov 16 12:19:38 2001
--- plpython.c Fri Nov 16 12:24:43 2001
***************
*** 292,297 ****
--- 292,298 ---- "binascii", "calendar", "cmath",
+ "codecs", "errno", "marshal", "math",
***************
*** 325,330 ****
--- 326,332 ---- "hexrevision", "maxint", "maxunicode",
+ "platform", "version", "version_info" };
