From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com> |
Subject: | Re: proposal: session server side variables |
Date: | 2017-01-02 07:53:47 |
Message-ID: | CAFj8pRB8PX57B+OF-fmY1cOpqD9dRqz543xV+GWj681CXdY-SA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2017-01-02 3:06 GMT+01:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:
>
>
> On 1 Jan. 2017 20:03, "Fabien COELHO" <coelho(at)cri(dot)ensmp(dot)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.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-01-02 08:40:23 | Re: safer node casting |
Previous Message | Amit Kapila | 2017-01-02 07:31:04 | Re: Odd behavior with PG_TRY |