Re: autonomous transactions - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: autonomous transactions
Date
Msg-id CANP8+jJU3ynRLPoN-p1VTABdXKd3PVWRcQ7TCC4x6axSkWvpCw@mail.gmail.com
Whole thread Raw
In response to Re: autonomous transactions  (Joel Jacobson <joel@trustly.com>)
Responses Re: autonomous transactions  (Joel Jacobson <joel@trustly.com>)
List pgsql-hackers
On 31 August 2016 at 14:09, Joel Jacobson <joel@trustly.com> wrote:
> On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova
> <jaime.casanova@2ndquadrant.com> wrote:
>>
>> On 30 August 2016 at 23:10, Joel Jacobson <joel@trustly.com> wrote:
>> >
>> > There should be a way to within the session and/or txn permanently
>> > block autonomous transactions.
>> >
>>
>> This will defeat one of the use cases of autonomous transactions: auditing
>
> My idea on how to deal with this would be to mark the function to be
> "AUTONOMOUS" similar to how a function is marked to be "PARALLEL
> SAFE",
> and to throw an error if a caller that has blocked autonomous
> transactions tries to call a function that is marked to be autonomous.
>
> That way none of the code that needs to be audited would ever get executed.

Not sure I see why you would want to turn off execution for only some functions.

What happens if your function calls some other function with
side-effects? How would you roll that back? How would you mark
functions for the general case?

Functions with side effects can't be tested with simple unit tests;
that has nothing to do with autonomous transactions.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Proposal for changes to recovery.conf API
Next
From: Corey Huinker
Date:
Subject: Re: proposal: psql \setfileref