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.
Cheers,
M
