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