Re: proposal: session server side variables

2016-12-29 14:25 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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.
>