Re: JDBC behaviour - Mailing list pgsql-jdbc

From Dave Cramer
Subject Re: JDBC behaviour
Date
Msg-id CADK3HH+qEKDLYpqpvObFhYvkc3PSJjzVdrFGb0zptL1mvhUZiQ@mail.gmail.com
Whole thread Raw
In response to Re: JDBC behaviour  (Sridhar N Bamandlapally <sridhar.bn1@gmail.com>)
Responses Re: JDBC behaviour
Re: JDBC behaviour
List pgsql-jdbc



On 22 February 2016 at 00:35, Sridhar N Bamandlapally <sridhar.bn1@gmail.com> wrote:

I may be wrong, please correct if, 

can we do function overloading to add functionality with savepoint option, i.e. with this both will be available and its app developers to chose

Can you be explicit in what you are asking for please ?

As John points out you can do this now by checking every commit. 





On Sat, Feb 20, 2016 at 11:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Bill Moran <wmoran@potentialtech.com> writes:
> On Sat, 20 Feb 2016 16:29:09 +0000
> Vitalii Tymchyshyn <vit@tym.im> wrote:
>> Well, I suppose replacing simple copy with procedural per-row function
>> would give huge performance hit. Also what method do you propose to use in
>> the code? Savepoints?

> Not at all. PL/PGSQL's ON ERROR handling can manage this without needing
> savepoints.

Actually, plpgsql's exception blocks *are* savepoints under the hood.
The backend engine does not have any way of recovering from errors other
than a (sub)transaction abort, which means you can't do this without a
savepoint or equivalent.

                        regards, tom lane


--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc


pgsql-jdbc by date:

Previous
From: John R Pierce
Date:
Subject: Re: JDBC behaviour
Next
From: Dave Cramer
Date:
Subject: Re: JDBC behaviour