On Tuesday 07 December 2010 20:17:57 Jan Urbański wrote:
> Hi,
>
> no, no patch(es) yet. I'm going through plpython.c trying as best I can
> to improve things there. I'll have a patch (or patches) ready for the
> January commitfest, but I thought I'd open up a discussion already to
> spare me having to redo features because the way I attacked the problem
> is a dead end. Be warned, this ended up being a very long email...
Nice to see improvements there.
> Currently the improvements are:
> * execute SPI calls in a subtransaction, report errors back to Python
> as exceptions that can be caught etc.
Youre doing that unconditionally? I think the performance impact of this will
be too severe... Subtransactions can get quite expensive - especially in the
face of HS.
> * remove volatile modifiers from variables (AIUI they are completely
> not necessary anywhere in plpython.c)
I havent read the code recently but they might be needed for local variables
changed inside a PG_TRY catching an error and also accessed in the CATCH block
or afterwards if youre not rethrowing.
See the man page of longjmp.
> * explicit subxact starting, so you can issue consecutive plpy.execute
> calls atomically
That likely obsoletes my comment from above.
> * split plpython.c into smaller modules, like plpython_traceback.c,
> plpython_type_conversion.c, plpython_plpy.c etc.
> * variadic argument handling (is this possible for a non-plpgsql pl?)
> * multiple OUT parameters support (a TODO item, I think "table function
> support" meant to say that)
> * add a DB-API interface on top of SPI (a TODO item)
I am not hot on that as dbapi simply is too unspecified in too many areas
(prepared statements anyone).
Thanks,
Andres