@@ -388,35 +388,6 @@ Branch: REL_14_STABLE [32a85ee46] 2022-06-06 11:26:57 -0400
388388
389389 <listitem>
390390<!--
391- Author: Michael Paquier <michael@paquier.xyz>
392- Branch: master [157f8739a] 2022-06-06 11:05:59 +0900
393- Branch: REL_14_STABLE [a04ccf6df] 2022-06-06 11:07:22 +0900
394- Branch: REL_13_STABLE [b364cfdfa] 2022-06-06 11:07:27 +0900
395- Branch: REL_12_STABLE [0a1e4f0ca] 2022-06-06 11:07:31 +0900
396- Branch: REL_11_STABLE [b0bd9327d] 2022-06-06 11:07:35 +0900
397- Branch: REL_10_STABLE [c3df4d53c] 2022-06-06 11:07:39 +0900
398- -->
399- <para>
400- Fix <application>psql</application>'s
401- <option>--single-transaction</option> option to consider client-side
402- errors as a reason to roll back the transaction (Kyotaro Horiguchi,
403- Michael Paquier)
404- </para>
405-
406- <para>
407- Previously, <application>psql</application> blindly
408- issued <command>COMMIT</command> at the end of
409- a <option>--single-transaction</option> session. Now it will
410- instead issue <command>ROLLBACK</command> if any errors were
411- detected. This makes no difference for server-detected errors
412- (because the server would then convert <command>COMMIT</command>
413- to <command>ROLLBACK</command> anyway), but it prevents committing
414- after a client-side error.
415- </para>
416- </listitem>
417-
418- <listitem>
419- <!--
420391Author: Tom Lane <tgl@sss.pgh.pa.us>
421392Branch: master [eb39610f8] 2022-06-01 16:15:47 -0400
422393Branch: REL_14_STABLE [1072e4c45] 2022-06-01 16:15:47 -0400