Re: Procedure support improvements

From: Greg Nancarrow <gregn4422(at)gmail(dot)com>
To: Dave Cramer <pg(at)fastcrypt(dot)com>
Cc: David Rader <david(dot)rader(at)gmail(dot)com>, pgsql-jdbc(at)lists(dot)postgresql(dot)org
Subject: Re: Procedure support improvements
Date: 2019-08-26 08:01:04
Message-ID: CAJcOf-fEHe9UCvsFXfiizeNUOjHu=WbzkzHM_Yi0Xs4=U8Gnng@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

>>
>> I'm sure that new users who start using PostgreSQL 11+, and those
>> migrating from other DBMSs, would have that kind of viewpoint. They'd
>> naturally be creating stored procedures for various complex reusable
>> processing (that does not necessarily need to commit/rollback
>> transactions within the procedure).
>
>
> I presume you have use cases that do not do transactions ?
>

What I was getting at here is that stored procedures can participate
in transactions, without having to control them (i.e. without issuing
COMMIT/ROLLBACK themselves).
For example, a client JDBC-based application might start a transaction
(auto-commit=FALSE), and invoke a couple of stored procedures as part
of the transaction, and then COMMIT the transaction (or ROLLBACK if an
exception is raised). The stored procedures in this case might
UPDATE/INSERT records; they are participating in the transaction, but
not explicitly controlling it.

Greg Nancarrow
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-08-26 08:57:01 Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free or corruption (!prev)
Previous Message Andrey Borodin 2019-08-26 07:59:11 Yet another fast GiST build

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Cramer 2019-08-26 14:16:32 [pgjdbc/pgjdbc] 36a75c: fix issue 1547, as long as peek returns some bytes...
Previous Message Steven Schlansker 2019-08-23 21:53:59 Re: Recommendations for PGBouncer interacting with HikariCP