From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: session server side variables |
Date: | 2016-12-28 14:31:27 |
Message-ID: | alpine.DEB.2.20.1612281523420.4911@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> Also, I'm not yet convinced that simple privatizable transcient/session
>> variables would not be enough to fit the use case, [...]
> So... maybe? The main question then becomes how you integrate access control.
For what it's worth, permissions on persistent functions could be used to
control access to private-to-a-role transcient/session variables, see:
https://www.mail-archive.com/pgsql-hackers(at)postgresql(dot)org/msg300651.html
The good point is that the implementation on top of session variables
would be trivial and very efficient, just prefix the variable with the
owner id in the key-value storage. The bad point is that there is no
full-featured GRANT on the variable itself, and it looks adhoc, somehow.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2016-12-28 14:38:39 | Re: proposal: session server side variables |
Previous Message | Peter Eisentraut | 2016-12-28 14:17:16 | make more use of RoleSpec struct |