Re: JDBC behaviour
På torsdag 18. februar 2016 kl. 13:22:15, skrev Mark Rotteveel <mark@lawinegevaar.nl>:
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
If that one failed statement doesn't raise an exception, how does the client (code) know that it failed? If it does raise an exception, then what standard specifies that that specific exceptions is to be treated as "don't rollback for this type of error"?
-- 
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
Вложения
В списке pgsql-jdbc по дате отправления: