On Thu, Sep 16, 2010 at 5:19 AM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
> Robert Haas <robertmhaas@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