Re: When extended query protocol ends?

>Is it possible for the JDBC
>driver to issue a Sync message before sending SAVEPOINT in simple
>query protocol?

Apparently, sending an extra message would increase the overhead of the
protocol, thus reducing the efficiency of the application.
What is the benefit of sending extra Sync?

https://www.postgresql.org/docs/current/protocol-overview.html#PROTOCOL-MESSAGE-CONCEPTS
suggests that is is fine to mix both simple and extended messages
depending on the needs of the application.

https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-FLOW-PIPELINING
reads that clients can omit sending Sync to make the error handling the way
they like.
I am not that sure we must omit sync there, however, it might be the case.

https://www.postgresql.org/docs/current/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY
reads "simple Query message also destroys the unnamed statement" and
"simple Query message also destroys the unnamed portal"

>Or you can send SAVEPOINT using the extended query protocol.

I am afraid we can't.
The purpose of savepoints at the driver's level is to enable migrating
applications from other databases to PostgreSQL.
In PostgreSQL any SQL exception fails the transaction, including errors
like "prepared statement \"...\" does not exist", and so on.
It might be unexpected for the users to unexpectedly get "prepared
statement is no longer valid" errors in case somebody adds a column to a
table.

We can't send complete parse-bind-execute commands for every "savepoint"
call as it would hurt performance.
We can't cache the parsed statement as it could be discarded by a random
"deallocate all".
So the only way out I see is to use simple query mode for savepoint queries.

Vladimir