Re: Using TEMP ON COMMIT DROP, but need logging too.

Поиск
Список
Период
Сортировка
От Michael Moore
Тема Re: Using TEMP ON COMMIT DROP, but need logging too.
Дата
Msg-id CACpWLjP5p9nm3mjB24xKJ3jkZy=og9T4nQahZQBggob8KfDzJA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Using TEMP ON COMMIT DROP, but need logging too.  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-sql
Thanks guys. Really appreciate it! Regards, Mike

On Fri, Oct 14, 2016 at 10:32 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:
On Fri, Oct 14, 2016 at 10:23 AM, Michael Moore <michaeljmoore@gmail.com> wrote:
This is VERY different than Oracle, but I think I know how it works now. My pgplsql function is going to be called via JDBC. This function is a replacement for an Oracle TABLE function. In Oracle PL/SQL, all commits and rollbacks are handled within the TABLE function. This means that the JDBC layer never has to deal with the transaction; only the session. Our Java coders never do Commit or Rollback. Since, from the Java code,  we are only changing the JDBC Driver (in order to migrate to Postgres), my new understanding is that the Java code will have to be responsible for try/catch(ing) any errors raised from pgplsql. The Java code must then decide weather a rollback or a commit is required. This will require a slight bit more coordination between the Java and pgplsql developer. 

Have I got this right?

​Yes, your application initiates and ends all transactions.  The JDBC merely provides a client API you can leverage to perform your work - and handles all of the protocol details.

David J.

В списке pgsql-sql по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Using TEMP ON COMMIT DROP, but need logging too.
Следующее
От: harish Reddy
Дата:
Сообщение: Fwd: Regarding change in the size of database