Re: JDBC behaviour

From: Sridhar N Bamandlapally <sridhar(dot)bn1(at)gmail(dot)com>
To: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
Cc: PG-General Mailing List <pgsql-general(at)postgresql(dot)org>, List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: JDBC behaviour
Date: 2016-02-18 08:26:59
Message-ID: CAGuFTBV14KqA_DmX-_=xefZq7QKn0DER73HbX+dkDehrssqtuw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers pgsql-jdbc

If we want transactions in "begin-end" then its fine,

but in this case all these transactions are independent with autocommit off,

user choice to continue with commit or rollback

Thanks
Sridhar

On Thu, Feb 18, 2016 at 1:43 PM, Vladimir Sitnikov <
sitnikov(dot)vladimir(at)gmail(dot)com> wrote:

> >Is it a bug or do we have other any alternate way to handle this ?
>
> PostgreSQL is strongly against "partial commits to the database". If
> you think a bit about it, it is not that bad.
> You got an error, what is the business case to commit the partial
> transaction then?
>
> Exceptions should not be used for a "control flow", should they?
>
>
> If you want to shoot yourself in a foot for fun and profit, you can
> try https://github.com/pgjdbc/pgjdbc/pull/477.
> What it does, it creates savepoints before each statement, then it
> rollbacks to that savepoint in case of failure.
>
> Vladimir
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andreas Joseph Krogh 2016-02-18 08:30:27 Re: JDBC behaviour
Previous Message Victor Blomqvist 2016-02-18 08:17:03 Query plan not updated after dropped index

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-02-18 08:30:17 Re: exposing pg_controldata and pg_config as functions
Previous Message Simon Riggs 2016-02-18 08:13:43 Re: pg_ctl promote wait

Browse pgsql-jdbc by date

  From Date Subject
Next Message Andreas Joseph Krogh 2016-02-18 08:30:27 Re: JDBC behaviour
Previous Message Vladimir Sitnikov 2016-02-18 08:13:39 Re: [JDBC] JDBC behaviour