On Thu, Sep 16, 2010 at 5:19 AM, Dimitri Fontaine <dfonta...@hi-media.com> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> One thing that strikes me (maybe this is obvious) is that the >> execution of the main transaction and the autonomous transaction are >> not interleaved: it's a stack. So in terms of globals and stuff, >> assuming you knew which things needed to be updated, you could push >> all that stuff off to the side, do whatever with the new transaction, >> and then restore all the context afterwards. > > I think they call that dynamic scope, in advanced programming > language. I guess that's calling for a quote of Greenspun's Tenth Rule: > > Any sufficiently complicated C or Fortran program contains an ad hoc > informally-specified bug-ridden slow implementation of half of Common > Lisp. > > So the name of the game could be to find out a way to implement (a > limited form of) dynamic scoping in PostgreSQL, in C, then find out all > and any backend local variable that needs that to support autonomous > transactions, then make it happen… Right?
Interestingly, PostgreSQL was originally written in LISP, and there are remnants of that in the code today; for example, our heavy use of List nodes. But I don't think that has much to do with this project. I plan to reserve judgment on the best way of managing the relevant state until such time as someone has gone to the trouble of identifying what state that is. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
