Re: When extended query protocol ends? - Mailing list pgsql-hackers

From Vladimir Sitnikov
Subject Re: When extended query protocol ends?
Date
Msg-id CAB=Je-HqHHqryuebk8MZGLpginRATRXHbP5_XvGG1arKtCWe0g@mail.gmail.com
Whole thread Raw
In response to Re: When extended query protocol ends?  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Responses Re: When extended query protocol ends?
List pgsql-hackers
>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?

suggests that is is fine to mix both simple and extended messages
depending on the needs of the application.

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.

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

pgsql-hackers by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: Patch: Add parse_type Function
Next
From: Jelte Fennema-Nio
Date:
Subject: Re: When extended query protocol ends?