Re: JDBC behaviour

Поиск
Список
Период
Сортировка
От Mark Rotteveel
Тема Re: JDBC behaviour
Дата
Msg-id 22d3da56ff9f987ede3d18de6e49423e@imap.procolix.com
обсуждение исходный текст
Ответ на Re: JDBC behaviour  (Dave Cramer <pg@fastcrypt.com>)
Ответы Re: JDBC behaviour  (Andreas Joseph Krogh <andreas@visena.com>)
Re: JDBC behaviour  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: JDBC behaviour
Следующее
От: Andreas Joseph Krogh
Дата:
Сообщение: Re: JDBC behaviour