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 stuffInterchance - 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
lowerlevels, 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'retransactional 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
Protocollevel, expose the Connection level, and leave everything else to further client software (libpq), and some
hidesthe 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
liketo have it and where we wouldn't. Having nontransactional behaviour is convenient for middleware that uses
preparedstatements 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
clashwith those of other layers, and this currently requires specific documentation. I would describe that as
anothernamespace 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
