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!