A.M. wrote:
>
> On May 24, 2007, at 14:29 , Wiebe Cazemier wrote:
>
> >On Thursday 24 May 2007 17:30, Alexander Staubo wrote:
> >
> >>[2] Nobody else has this, I believe, except possibly Ingres and
> >>NonStop SQL. This means you can do a "begin transaction", then issue
> >>"create table", "alter table", etc. ad nauseum, and in the mean time
> >>concurrent transactions will just work. Beautiful for atomically
> >>upgrading a production server. Oracle, of course, commits after each
> >>DDL statements.
> >
> >If this is such a rare feature, I'm very glad we chose postgresql.
> >I use it all
> >the time, and wouldn't know what to do without it. We circumvented
> >Ruby on
> >Rails' migrations, and just implemented them in SQL. Writing
> >migrations is a
> >breeze this way, and you don't have to hassle with atomicity, or
> >the pain when
> >you discover the migration doesn't work on the production server.
>
> Indeed. Wouldn't it be a cool feature to persists transaction states
> across connections so that a new connection could get access to a sub-
> transaction state? That way, you could make your schema changes and
> test them with any number of test clients (which designate the state
> to connect with) and then you would commit when everything works.
>
> Unfortunately, the postgresql architecture wouldn't lend itself well
> to this. Still, it seems like a basic extension of the notion of sub-
> transactions.
Hmm, doesn't this Just Work with two-phase commit?
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
Oh, oh, las chicas galacianas, lo harán por las perlas,
¡Y las de Arrakis por el agua! Pero si buscas damas
Que se consuman como llamas, ¡Prueba una hija de Caladan! (Gurney Halleck)
