Tom Lane wrote: > > Manfred Koizar <[EMAIL PROTECTED]> writes: > > A *stack* of _active_ transaction numbers is not sufficient, we need > > the whole *tree* of _all_ transactions belonging to the current top > > level transaction. This is, want I wanted to model in my pg_subtrans > > "table". And pg_subtrans cannot be a private structure, because it > > has to be inspected by other transactions too (cf. example above). > > Hmm. This seems to me to be vastly overdesigning the feature. I've > never yet seen a practical application for more than one level of > subtransaction, so I question whether we should buy into a substantially > more complex implementation to support the more general case.
I'm for Manfred with this point. I would never suppose that nested transactions supports only 1 level. > > > Is this really related to subtransactions? The current behaviour is, > > that an error not only aborts the offending command, but the whole > > (top level) transaction. My proposal doesn't change anything > > regarding this. > > Every single application that I've seen for subtransactions is all about > error recovery. If we don't fix that then there's no point. The problem exists with any implementation. Though tuple validity checking may be only a small part (I don't think so), I've never seen such proposal other than Manfred's one. If I remember correctly, savepoints functionality was planned for 7.0 but probably we wouldn't have it in 7.3. The TODO may be a TODO for ever unless the direction to solve the TODO is decided. 1) without UNDO for individual tuples. 2) with UNDO for individual tuples under no overwriting smgr. 3) UNDO under overwriting smgr. regards, Hiroshi Inoue http://w2422.nsk.ne.jp/~inoue/ ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org