Re: [subxact] Proof-of-concept: report nest level to client

Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> 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 SCROLL.

> 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.

-O