Re: [HACKERS] proposal: session server side variables
| От | Pavel Stehule |
|---|---|
| Тема | Re: [HACKERS] proposal: session server side variables |
| Дата | |
| Msg-id | CAFj8pRC17o-8+QPZuN_PEzmibEJcm3LswfwA-xt0J1DTAULcLg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] proposal: session server side variables (Fabien COELHO <coelho@cri.ensmp.fr>) |
| Ответы |
Re: [HACKERS] proposal: session server side variables
Re: [HACKERS] proposal: session server side variables |
| Список | pgsql-hackers |
2016-12-29 14:25 GMT+01:00 Fabien COELHO <coelho@cri.ensmp.fr>:
I newer talked about persistent data. I talked about persistent metadata.
Sure, I finally understood that detail. Now if I hear "persistent variable", I by default understand that both metadata and data are persistent... It requires some effort to understand the subtelty.I really don't propose any possible substitution of tables (relations). I newer did it.
Sure.The used terminology is not 100% clean and natural - maybe better name is
"global temporary unshared untransactional unrelational storage" -
Hmmm. Too long:-) But these properties need to be spelled out.[...] I don't see any sense to have two similar storages or two redundant access methods - not in PostgreSQL level.
Then say so in the wiki in the cons.
Personnaly, I'm not sure. Maybe having a clean way of declaring a one-row "singleton" table enforced by postgresql would be enough.
There is a singleton table :)
create table foo(x integer unique not null default 1 check(x = 1), y integer);
insert into foo(y) values(100);
analyze foo;
The storage is not important and is not interesting - any different behave for persistent objects different than MVCC can be big surprise for users.
What is interesting are getter functions - they can be volatile or stable/immutable - what can be interesting, because then the value can be used by planner.
For example - MySQL @var is volatile - can be changed in query - that's mean, you cannot use it as const for planner :( - the behave will be same (with same risks to performance) like using plpgsql variable in query.
With getter functions you can do bigger game.
Regards
Pavel
--
Fabien.
В списке pgsql-hackers по дате отправления: