2016-12-29 14:41 GMT+01:00 Pavel Stehule <pavel.steh...@gmail.com>: > > > 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. >
our sequences - simple, persistent, and not ACID - I found lot of people that cannot accept it - not quickly > > 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. >> > >
