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.
