On Sun, Jul 11, 2004 at 07:23:13PM -0400, Bruce Momjian wrote: > > Were are we on deciding how PREPARE in aborted transactions should behave?
Haven't gotten much further than agreeing that current behaviour is quirky. It does not follow that we agree it's bad. I would say most of us agree that it may have been a little rash to unify prepared statements on the fe/be protocol level and those on the SQL level into the same namespace. One piece of progress we did make is a layercake model to facilitate discussion of the fe/be protocol and other interface issues: SQL session - tables & queries and stuff Interchance - dat a representation, encodings &c. Protocol - bind/prepare/execute, portals &c. Connection - sockets and such Some observations we can make based on this: - Transactionality plays at the upper three levels. Should the upper level be exclusively transactional? In other words, should we have an ACID SQL implementation? This issue can in principle be separated from any choices at the lower levels, but currently prepared statements and cursors cross the divide. - Session variables see significant use at the Interchange level, yet are manipulated at the SQL level. This means they're transactional although some would like to see them work nontransactionally. - To make things easier we've lumped everything between the client socket and client-side business logic under the term "middleware." - Some middleware such as language drivers hide only the lowest levels but leave SQL alone (JDBC), or hide only the Protocol level, expose the Connection level, and leave everything else to further client software (libpq), and some hides the lower 2 levels, gets involved in the upper level, but doesn't touch the Interchange level (libpqxx). This may influence how easy it is for the middleware to support transactionality for various features, and where we would like to have it and where we wouldn't. Having nontransactional behaviour is convenient for middleware that uses prepared statements and is not transaction-aware. - There is also a layercake at the client side. Middleware's naming choices for e.g. prepared statements must not clash with those of other layers, and this currently requires specific documentation. I would describe that as another namespace problem. Basically the whole problem probably wouldn't be with us if prepared statements on the SQL level were different from the identically-named concept in the fe/be protocol. Jeroen ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings