Re: JDBC behaviour

On 22 February 2016 at 23:06, Sridhar N Bamandlapally <sridhar(dot)bn1(at)gmail(dot)com
> wrote:

>
> I mean, we will not change existing functionality/behavior/code as there
> may be dependency applications with same behavior
>
> i.e. currently conn.setAutoCommit (false) is using "BEGIN;"
>

Yes, this is the exact definition of what setAutoCommit(false) is.

>
> and the new functionality can be like conn.setAutoCommit(false,
> <new-parameter> ), where new-parameter can be Boolean or flag which does
> following way for statements
>

This is completely incompatible with the spec. You can't just add
parameters to methods, and expect it to be compatible.

This below is exactly what PR477 is meant to do. If you want to be
constructive test this https://github.com/pgjdbc/pgjdbc/pull/477 and
provide feed back

>
> try
> {
> conn.savepoint(SP);
> SQL-statement;
> }
> catch(Exception exp)
> {
> conn.rollback(SP);
> throw exp;
> }
>
>
>

Dave

>
>>
>>
>> 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
>>>>
>>>
>>>
>>
>