On Wed, Aug 31, 2016 at 6:22 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 31 August 2016 at 14:09, Joel Jacobson <j...@trustly.com> wrote: >> 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?
I'm not sure I understand your questions. All volatile functions modifying data have side-effects. What I meant was if they are allowed to commit it even if the caller doesn't want to. However, I'll try to clarify the two scenarios I envision: 1. If a function is declared AUTONOMOUS and it gets called, then that means nothing in the txn has blocked autonomous yet and the function and any other function will be able to do autonomous txns from that here on, so if some function would try to block autonomous that would throw an error. 2. If a function has blocked autonomous and something later on tries to call a function declared AUTONOMOUS then that would throw an error. Basically, we start with a NULL state where autonomous is neither blocked or explicitly allowed. Whatever happens first decides if autonomous transactions will explicitly be blocked or allowed during the txn. So we can go from NULL -> AUTONOMOUS ALLOWED or NULL -> AUTONOMOUS BLOCKED, but that's the only two state transitions possible. Once set, it cannot be changed. If nothing in an application cares about autonomous transactions, they don't have to do anything special, they don't need to modify any of their code. But if it for some reason is important to block autonomous transactions because the application is written in a way where it is expected a RAISE EXCEPTION always rollbacks everything, then the author of such an application (e.g. me) can just block autonomous transactions and continue to live happily ever after without having to dream nightmares about developers misusing the feature, and only use it when appropriate. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
