Re: [HACKERS] proposal: session server side variables

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.

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.