| From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
|---|---|
| To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
| Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Fabrízio de Royes Mello <fabriziomello(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-29 10:42:45 |
| Message-ID: | alpine.DEB.2.20.1612291128370.4911@lancre |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> yes, I'll do it.
>
> But I'll remove some strange ideas.
Why?
I rather expect that you would comment that you find them strange and
argue why: there is no reason to "remove" a concept idea as such at least
early in a discussion process...
> Why persistent variables?
Because *you* want persistent session variables... I did not invent it,
I just removed the "session" word and generalized the concept.
Sometimes one wants to store sets, sometimes one wants to only store
value.
> Please, one argument. We have tables. What is wrong on tables?
Nothing is wrong as such. Cons arguments are: the syntax is verbose just
for one scalar, and the one-row property is currently not easily enforced
by pg, AFAIK.
Note that I'm not claiming that it should be implemented, but if some kind
of half-persistent variables are implemented, I think it should be
consistent with possibly fully-persistent variable as well, even if they
are not implemented immediately, or ever.
> Anything what will be persistent will have similar performance like
> tables.
Yes, sure. It is a different use case. Argue in the wiki!
--
Fabien.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fabien COELHO | 2016-12-29 10:44:46 | Re: proposal: session server side variables |
| Previous Message | Fabien COELHO | 2016-12-29 10:28:11 | Re: proposal: session server side variables |