Re: why postgresql over other RDBMS

[Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>]

At 03:25 AM 5/25/2007, A.M. wrote:

> 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.

I've proposed this for postgresql before (7 years ago?), but for a 
different reason. Didn't seem to get much interest though.

The idea was people wouldn't have to reinvent/reimplement 
transactions for stuff like webapps. Of course you might have to have 
a separate database for "shopping cart" or other "persistent" 
transactions, so that outstanding transactions don't cause lots of 
nonrelated transient rows to be kept unreclaimable.

And also I was thinking it would be good to decouple the maximum 
number of concurrent transactions supported by postgresql from the 
maximum number of concurrent connections supported.

Issues: what should happen if multiple connections try to continue 
the _same_ transaction.

Also should keep in mind clustering support though - this might 
create interesting problems and features in a clustering scenario :).

Regards,
Link.