Re: proposal: session server side variables

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: 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>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Subject: Re: proposal: session server side variables
Date: 2017-01-02 02:06:46
Message-ID: CAMsr+YHZWVi6XQTy3Lu4RZLjJ0FjxuYzYe72qBBkHYt-COgb+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2017-01-02 02:17:12 Re: WIP: [[Parallel] Shared] Hash
Previous Message rightfold 2017-01-01 23:20:54 gen_random_uuid security not explicit in documentation