Re: proposal: session server side variables

2016-12-29 14:41 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
> 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.
>

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.
>>
>
>