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 13:19:45 |
Message-ID: | alpine.DEB.2.20.1612281335360.4911@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-12-28 13:24:58 | Re: proposal: session server side variables |
Previous Message | Michael Banck | 2016-12-28 13:17:58 | Re: Reporting planning time with EXPLAIN |