Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id CAFj8pRB8PX57B+OF-fmY1cOpqD9dRqz543xV+GWj681CXdY-SA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: [HACKERS] proposal: session server side variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers


2017-01-02 3:06 GMT+01:00 Craig Ringer <craig@2ndquadrant.com>:


On 1 Jan. 2017 20:03, "Fabien COELHO" <coelho@cri.ensmp.fr> wrote:


What if setup_user() succeeds as a function but the transaction it belongs to fails for some reason (eg deferred constraints, other operation related to setting user up but outside of this function fails, there is replication issue... whatever, a transaction may fail by definition)?

ISTM that the security models requires that USER_IS_AUDITOR is reverted, so although it is definitely a session variable, it must be transactional (MVCC) nevertheless.

No strong opinion here.

IMO the simplest answer should be the main focus here: if it's session level, it's session level. Not kinda-sesion-level kinda-transaction-level.

I can see occasional uses for what you describe though. If we landed up with an xact scope option like we have for SET LOCAL GUCs, the option to mark it ON COMMIT RESET or ON COMMIT SET would be useful I guess. I'm not sure if it's worth the complexity.

In my proposal was support for transaction scope - ON COMMIT RESET clause should be ok

Regards

Pavel
 

I guess defaulting to rolling back variable effects on xact rollback would be ok too. Just kind of limiting.

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Odd behavior with PG_TRY
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] safer node casting