Thought another message might be appropriate as I've made some
progress: finished up PEP302 interfaces on PyPgFunction
objects(provides linecache support for tracebacks), IST support, DB
error handling(pg error -> pyexc -> pg error), and, recently, some
annoying type interface improvements..
Some of those features in action: IST tests, error tests. Also,
I started on a WIP wiki page covering my progress and a small amount
of documentation for anyone curious enough to play with it.
[some notes; feel free to swing the cluebat =]
In order to implement IST support and error handling, the PL has to
keep track of the number of open ISTs, and whether or not the code
executed by the PL caused a database error.
Tracking the error state is needed so that some (most) Postgres
interfaces will not be invoked inside a failed transaction, and so
that the PL will not exit without indicating an error state(elog/
ereport), and so that the PL will not try to commit a failed
subtransaction on IST __exit__.
Tracking the number of open ISTs is needed so that the PL can properly
clean up after any misused Postgres.Transaction objects. When this
situation is presented to the PL, all the excess ISTs that remained
open will be aborted and an error will be thrown.
At this point, the major items remaining are: SPI interfaces,
polymorphic functions, array & composite interfaces(the objects can be
created and passed around, but the item/element access methods are
completely untested, ATM), whatever random bugs popup/minor cleanupS,
and, of course, documentation. Still lots to do.
pgsql-hackers by date
|Next:||From: Josh Berkus||Date: 2009-08-21 19:14:12|
|Subject: Re: Feedback about Drupal SQL debugging|
|Previous:||From: email@example.com||Date: 2009-08-21 18:41:30|
|Subject: Re: Lazy Snapshots|