Re: why postgresql over other RDBMS

Surely such a use case could, and more to the point *should* be met
using PITR?
Regards,
- Naz.

Alvaro Herrera wrote:
> 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?
>
>