Re: When extended query protocol ends?

Jelte> If the Execute causes an error, is
Jelte> the Query still executed or not? And what about if the Query fails,
is
Jelte> the Execute before committed or rolled back?

Frankly, if there's a requirement from the backend, I would like it to
produce a corresponding error message.

What do you think of making the backend respond with an error message if
the requests come out of sequence?
For instance, if execute comes without parse, backend responds with "ERROR:
prepared statement "..." does not exist"

Can we have a similar diagnostic to catch the unspoken rule of
"sync should be there in-between extended messages and simple/functioncall
messages and copy subprotocol"?

If "extended query" is supposed to be like a subprotocol which allows no
extra messages,
then it would help if the documentation enumerated the subprotocols and
their messages.

For instance, for copy, the documentation is clear; it goes with a
subprotocol, so only specific messages are allowed.

-----

Jelte>And only extended protocol
Jelte>messages are allowed to be part of a pipeline: "Use of the extended
Jelte>query protocol allows pipelining"

Frankly speaking, I think there's a misunderstanding of "pipelining"

The full quote is

pgdoc>"Use of the extended query protocol allows pipelining,
pgdoc>which means sending a series of queries without waiting for earlier
ones to complete"

The key is "without waiting for earlier ones to complete".
However, in Simple Query section, the documentation reads that
the frontend does not need to wait for the response:

pgdoc>It is not actually necessary for the frontend to wait for
ReadyForQuery before issuing another command"

In other words, SimpleQuery supports pipelining just as fine, and there's
nothing special in "extended query" in that regard.

Vladimir