Re: [Re] Re: PREPARE and transactions

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