Re: JDBC behaviour

Поиск
Список
Период
Сортировка
От Sridhar N Bamandlapally
Тема Re: JDBC behaviour
Дата
Msg-id CAGuFTBXZ-CF8BRw9E-QcUBQ9UKSSYrZVqF8vwm18EsvJfbiOjw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: JDBC behaviour  (Dave Cramer <pg@fastcrypt.com>)
Ответы Re: JDBC behaviour  (Dave Cramer <pg@fastcrypt.com>)
Re: JDBC behaviour  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-jdbc
Дерево обсуждения

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

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 

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



autocommit is not option as end-user need control/decision to commit or rollback on successful transactions

our applications build with Oracle, SQL-Sever compatible ( i.e. using setAutCommit FALSE at every transaction ), 
now are migrating applications compatible with PostgreSQL on cloud, 


Thanks
Sridhar



On Mon, Feb 22, 2016 at 3:56 PM, Dave Cramer <pg@fastcrypt.com> wrote:



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 по дате отправления:

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