Re: JDBC behaviour

On 22 February 2016 at 00:35, Sridhar N Bamandlapally <sridhar(dot)bn1(at)gmail(dot)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.

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

>
>
>
>
> On Sat, Feb 20, 2016 at 11:01 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Bill Moran <wmoran(at)potentialtech(dot)com> writes:
>> > On Sat, 20 Feb 2016 16:29:09 +0000
>> > Vitalii Tymchyshyn <vit(at)tym(dot)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(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>
>
>