On Tue, Mar 17, 2020 at 07:15:05PM -0400, Dave Cramer wrote:
> On Tue, 17 Mar 2020 at 16:47, Bruce Momjian <bruce@momjian.us> wrote:
> Third, the idea that individual interfaces, e.g. JDBC, should throw an
> error in this case while the server just changes the COMMIT return tag
> to ROLLBACK is confusing. People regularly test SQL commands in the
> server before writing applications or while debugging, and a behavior
> mismatch would cause confusion.
>
>
> I'm not sure what you mean by this. The server would throw an error.
I am saying it is not wise to have interfaces behaving differently than
the server, for the reasons stated above.
> Fourth, it is not clear how many applications would break if COMMIT
> started issuing an error rather than return success a with ROLLBACK tag.
> Certainly SQL scripts would be fine. They would have one additional
> error in the script output, but if they had ON_ERROR_STOP enabled, they
> would have existed before the commit. Applications that track statement
> errors and issue rollbacks will be fine. So, we are left with
> applications that issue COMMIT and expect success after a transaction
> block has failed. Do we know how other database systems handle this?
>
> Well I know pgjdbc handles my patch fine without any changes to the code
> As I mentioned upthread 2 of the 3 go drivers already error if rollback is
> returned. 1 of them does not.
Good point.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +