2016-12-29 14:25 GMT+01:00 Fabien COELHO <coe...@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. >
