Re: proposal: schema PL session variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: schema PL session variables
Date
Msg-id CAFj8pRAfZfNBd3RFwwZiztN3n+KddTGPoe_2+HStc_NiGzb+VA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: schema PL session variables  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers


2016-02-10 20:25 GMT+01:00 Jim Nasby <Jim.Nasby@bluetreble.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

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: schema PL session variables
Next
From: Tom Lane
Date:
Subject: Moving responsibility for logging "database system is shut down"