Re: proposal: session server side variables

2016-12-26 17:15 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> Hello Pavel,
>
> SET ROLE Admin;
>>> DECLARE @secure_variable INTEGER RESTRICT; -- only accessible to Admin
>>>
>>
> Why introduce another security system?
>>
>
> That is a good question.
>
> I would prefer to avoid it and just have simple session variables... but
> this is not what you want, so I'm trying to find a compromise which both
> gives you the feature you are seeking and would keep session variables as
> inexpensive, i.e. without catalog costs.
>
> A simplistic PUBLIC/PRIVATE permissions on simple session variable can be
> done with nothing (no additional data structures): (store: hash_put(<owner
> id if private or nothing> || '@varname', value); consult: if exists(<owner
> id> || '@varname') then return it else if exists('@varname') then return it
> else "error variable does not exist").
>
> Now if you can offer an inexpensive GRANT/REVOKE on simple session
> variables, i.e. without catalog changes, then I think I would agree to it,
> even if I would not like it much.
>

> The reason I "do not like much" is subjective. I associate SQL permission
> commands (GRANT, REVOKE...) to real SQL "objects" (i.e. persistent,
> transactional, secured things subject to CREATE ALTER DROP...). However
> light-weight session variables are not really like that.
>
> Also if you can have inexpensive GRANT/REVOKE then probably I would also
> have to accept "CREATE SESSION VARIABLE @foo", because it would be
> consistent to have it with GRANT/REVOKE. I would "not like it much" either
> to have CREATE for an non persistant object, but that is life...
>
> However I understood that for permissions you do need "pg_class", which
> means catalog changes on session variable creation, which means expensive
> for simple session variables, so not desirable.
>

I don't understand to "expensive" word. How much often you create/drop
these variables? The deployment cycle is similar to functions. I don't
propose any feature, that can enforce bloating of system catalogue.

The variable metadata will be persistent across sessions. I can imagine the
local (temporal) session variable where life cycle of metadata will be
related to session like our current temporary tables. But it is not in this
proposal.

Regards

Pavel

> --
> Fabien.
>