Re: [Re] Re: PREPARE and transactions

On Sat, Jul 03, 2004 at 12:16:50PM +1200, Oliver Jowett wrote:

> I stand by my original statement: making no change does not break
> compatibility. Please provide an example of PREPARE/EXECUTE use that
> works under 7.3/7.4 but does not work with current 7.5.

Whether the transaction from "7.3/7.4" to "7.5" (as it stands) breaks
compatibility was never at issue here. There would be no point: this break
is _between_ 7.3 and 7.4. Middleware can no longer assume that rolling
back will get it out of the changes it was making at the SQL level, unless
it is in exclusive control of prepared statements.

> Parse/Bind/Execute interact with PREPARE/EXECUTE -- they share a
> namespace. Quirky as the current behaviour is, it'd be even quirkier if
> PREPARE/EXECUTE had substantially different semantics to Parse/Bind/Execute.
>
> Please do read the V3 protocol spec:
> http://developer.postgresql.org/docs/postgres/protocol.html

Ah, now I see. This is why some have proposed to change the SQL behaviour
(which is what I'm concerned with) but not the protocol. That seemed
strange to me before, but it makes more sense now.

I guess the question then becomes: should we see the frontend-backend
protocol as a transport layer underneath, and conceptually separate from,
the SQL session? Or should the protocol be allowed to shine through in
the way SQL itself is supported, and vice versa, so the two can share code
and concepts?

My point of view in this is the layered one, i.e. I'd like to be able to
"speak SQL" to the server, as I'm doing now through libpq, and ignore how
it gets there--at least as far as the SQL itself is concerned. Call it a
2.0 vantage point. From that angle there are no problems with giving the
protocol's bound statements and SQL's prepared statements both different
namespaces and different behaviour.

You seem to be taking the other view, where now that we have the extended
query protocol, it makes no sense to have one behaviour for the protocol
and another for SQL--and since the protocol implementation is not subject
to transactions (except that portals live in transactions?) there is no
point in going with transactional behaviour for a mechanism shared between
both.

Does that more or less describe the underlying controversy?

Jeroen