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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
