Re: proposal: session server side variables

2016-12-29 11:42 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> 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.
>

I newer talked about persistent data. I talked about persistent metadata. I
really don't propose any possible substitution of tables (relations). I
newer did it.

The used terminology is not 100% clean and natural - maybe better name is
"global temporary unshared untransactional unrelational storage" - when I
use a terminology related to temporary tables.

I don't see any sense to have two similar storages or two redundant access
methods - not in PostgreSQL level.

>
> 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.

There is small language barrier :) - I am thinking about features, what we
should to implement, not what can be implemented. There is lot of
possibilities, that we can find in universe. But only few has
technical/practical sense.

SQL is verbose language - I like it - because it different - the developer
have to know when he is working with database, with persistent data. The
cost of access to data is significantly higher. When this information is
hidden from developer, then the result is terrible slow.

Regards

Pavel

>
>
> Anything what will be persistent will have similar performance like tables.
>>
>
> Yes, sure. It is a different use case. Argue in the wiki!
>
> --
> Fabien.
>