Steps to Reproduce:
Run PostgresClient.execute with an INSERT statement and a List<Tuple> where the first Tuple can be successfully inserted but the second Tuple can't (for example duplicate primary key).
No Tuple of the List is inserted. All or nothing. The batch operation is atomic.
The first tuple is inserted and kept. No roll-back.
A failure is reported, however, no information how many tuples succeeded.
If the INSERT command contains a RETURNING clause the RETURNING values of the succeeding INSERT of the first Tuple is not reported.
The vertx-sql-client postgres driver has a executeBatch method that is atomic because it is implemented as a single command: https://github.com/eclipse-vertx/vertx-sql-client/blob/4.0.3/vertx-pg-client/src/main/java/io/vertx/pgclient/impl/codec/ExtendedQueryCommandCodec.java#L51-L60
Using executeBatch gives better performance.
Switching the implementation from non-atomic to atomic is a bug fix and not a breaking change because we havn't documented that PostgresClient.execute is non-atomic and because PostgresClient.execute does not report the RETURNING values of the succeeding tuples that were inserted before the failing tuple.