Re: proposal: session server side variables

2016-12-28 14:19 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> Hello Craig,
>
> Fabien, I don't really see the point of "persistent variables". What
>> benefit do they add over relations?
>>
>
> A relation is a set of values, a variable is a scalar with one value.
>
> It is always possible to declare a set and use it as a singleton, but
> somehow it seems cleaner to ask for what you want and have the database
> maintain the singleton property just like any other constraint.
>
> Behind the scene a "persistent variable" would probably be implemented as
> a row in a special table or some kind of one-row table... So there is no
> deep semantical difference, but mostly a syntactic one: you ask for a
> variable and you use it as a variable, i.e. there can be a simple well
> integrated syntax to get its value without having to "SELECT FROM" or
> resorting to functions.
>
> You can add a simple function to fetch a tuple if you want it not to
>> look like a subquery.
>>
>
> ISTM that if there are some kind of (persistent/session/...) variables,
> there should be a simple direct way of getting its value, like @var or &var
> or whatever. If one must write pg_get_variable_value('var')::ZZZ, it
> somehow defeats the purpose, as "(SELECT var FROM some_table)" is shorter.
>

just note - getter function returns typed value - there are not necessary
any other casting

>
> I do see value to two different things discussed here:
>>
>> * Pavel's proposal for persistent-declaration, non-persistent-value
>> session variables with access control. [...]
>>
>
> Yep, that is one. I missed the half-persistence property at the
> beginning...
>
> * Fabien's earlier mention of transient session / query variables, a-la
>> [...] I think it's a very separate topic to this and should be dealt with
>> in a separate thread if/when someone wants to work on them.
>>
>
> Yes and no: ISTM that at least a global design should be discussed
> *before* some kind of special-case variables (session-alive,
> persistent-in-existence-but-not-in-value, not-transactional,
> subject-to-permissions, not-subject-to-constraints...) are introduced, so
> that the special case does not preclude the possible future existence of
> other types of variables.
>
> Then I would be more at ease with having a special case implemented first,
> knowing that others may come and fit neatly, both semantically and
> syntaxically.
>
> I'm bothered by the half-persistence proposed, because it interferes both
> with possible session (light-weight, only in memory) and persistent
> (heavy-weight, in catalog) variables.
>
> Also, I'm not yet convinced that simple privatizable transcient/session
> variables would not be enough to fit the use case, so that for the same
> price there would be session variables for all, not only special ones with
> permissions.
>
> --
> Fabien.
>