Re: JDBC behaviour - Mailing list pgsql-jdbc

From Mark Rotteveel
Subject Re: JDBC behaviour
Date
Msg-id 22d3da56ff9f987ede3d18de6e49423e@imap.procolix.com
Whole thread Raw
In response to Re: JDBC behaviour  (Dave Cramer <pg@fastcrypt.com>)
Responses Re: JDBC behaviour  (Andreas Joseph Krogh <andreas@visena.com>)
Re: JDBC behaviour  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
List pgsql-jdbc
On Thu, 18 Feb 2016 07:15:11 -0500, Dave Cramer <pg@fastcrypt.com> wrote:
> On 18 February 2016 at 07:09, Mark Rotteveel <mark@lawinegevaar.nl>
wrote:
>
>> On Thu, 18 Feb 2016 11:59:50 +0100 (CET), Andreas Joseph Krogh
>> <andreas@visena.com> wrote:

>> > You simply cannot have batch-inserts in the same transaction and
>> expecting
>> > the
>> > batch not to fail if one of the statements in the batch fails.
>>
>> On a lot of other database systems, that is exactly how it works. If a
>> statement fails, that one statement is backed out (rolled back), and it
>> is
>> still up to the user to decide if he wants to commit or rollback the
>> statements that did succeed.
>>
>
> This behaviour is an artifact of PostgreSQL. If you want to change the
> transaction semantics of PostgreSQL then pgsql-hackers is the place to
take
> this up.
>
> JDBC is just an interface. We aren't going to rewrite the backend
semantics
> to meet everyones needs/wants.

I understand that and indeed this isn't something that should be handled
by the driver, however some of the response in this thread seem to think it
is an absurd expectation from the OP that failure of one statement should
still allow a commit. Which it isn't if you look at what other database
systems do.

Mark


pgsql-jdbc by date:

Previous
From: Dave Cramer
Date:
Subject: Re: JDBC behaviour
Next
From: Andreas Joseph Krogh
Date:
Subject: Re: JDBC behaviour