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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
