Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:

Patch attached (surprinsingly small), though it only applies with the
savepoint patch applied(*).  If any driver writer wants to play, however,
it's easy to see what's going on -- a ParameterStatus message will be
received from the backend whenever the nesting level changes.

This is really quite the wrong behavior --- think about a function that
executes thousands of subtransactions before returning.  You really do
not want to emit a message for every nestlevel change.  (That's one of
the reasons I rejected doing this as a regular GUC variable.)

We could possibly send the info as a fake ParameterStatus that's only
sent just before the Z message, ie only when the backend is about to
wait for a command.

This is not really sufficient when using the extended query protocol to run several queries before a Sync. Consider "SAVEPOINT foo; SELECT ...; SAVEPOINT bar; SELECT ..." run as (Parse/Bind/Execute)x4 + Sync. If the client wants to track the nesting level of portals returned by the Bind messages -- so it can know when they're invalidated on rollback -- it can't if the level is only given in ReadyForQuery.

What about emitting any nesting level change once at the end of processing each protocol message? More specifically I think Execute and Query are the only messages that should change nesting level?

- need for option to make protocol-created portals act like WITH HOLD cursors


and IIRC we have identified some other minor misfeatures in the 7.4
protocol design as well, though I'd have to dig through the archives
to remember the details.  If we find any more I'll start to think that
we should just do it ...

One change I thought might be useful is to include the name of the opened or closed portal or statement in ParseComplete, BindComplete, CloseComplete messages. A V3 client that's streaming multiple commands before a Sync has to do some extra work to track exactly which resources it's allocated, remembering the exact order it requested operations and matching them up to the (anonymous) responses it gets.

Also on my wishlist is a message whenever a portal is implicitly closed (perhaps a spontaneous CloseComplete?) although I have no idea how hard this is to implement :)

There was also a brief discussion earlier around defining exactly when in the protocol stream the client encoding changes after a SET client_encoding (and the encoding of the startup packets). This might just be documentation.

But none of these are important enough to force a protocol change by themselves.


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
     joining column's datatypes do not match

Reply via email to