Re: proposal: schema PL session variables

2016-02-10 20:25 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>:

> On 2/10/16 1:17 PM, Pavel Stehule wrote:It is too simple and too like
> workaround :) I can do it this in plpgsql
>
>> extension probably.
>>
>
> I think it's something people will definitely want. If we don't have it,
> then they're going to be using schema variables as a work-around because
> they can't do a private static variable inside a single function.
>

the schema variables can be used for different purpose, but different
direction isn't possible. So I am starting with schema variables.

But schema variables doesn't block implementation private static variables,
and probably if we will have static variables, then schema variables can
reuse (or use) related code well.

>
> Most importantly, since this effects only plpgsql and only
>> individual functions, the design is simple and should be easy to
>> commit in 9.6. I don't have the same confidence with schema variables.
>>
>>
>> My target is not 9.6 - next commitfest will be full - finishing multi
>> CPU queries, logical replication, .. and I have still three opened
>> patches. But if we find a agreement in this spring, I can implement it
>> in summer, and it can be in upstream in early 9.7 commitfest. I know,
>> this topic is difficult, so have to start it now.
>>
>
> Sure. I think it would be useful to have a wiki page with info as it gets
> ironed out. A good starting point would be use cases. One that I don't
> think has been considered is different extensions adding/using different
> schema variables. Questions like should extension A have direct access to
> variables for extension B.

yes, it is question.

My reply is - not (my opinion), minimally in first iteration. a) I can use
a functions, b) direct sharing content (variables) between extensions,
schemas is not recommended generally (it is not just only my idea).

second question is "why you need direct access to variables between
extensions, schemas?". Can you write some use cases?

Maybe we need a different class for this purpose - some stream (pipe)
between extensions. But this is out of this scope. Although it is pretty
valid.

Regards

Pavel

>
> --
> Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
> Experts in Analytics, Data Architecture and PostgreSQL
> Data in Trouble? Get it in Treble! http://BlueTreble.com
>