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.