2016-02-10 20:10 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com>: > On 2/10/16 1:04 PM, Pavel Stehule wrote: > >> >> BTW, if all that's desired here are session variables for plpgsql, I >> think it makes a lot more sense to start with implementing >> per-function session variables. That's a lot simpler design-wise and >> is something we should have anyway. You don't necessarily want >> session variables to be schema-level. (I realize the other PLs make >> them global, which is even worse, but that's no reason to continue >> that path.) >> >> >> I am not able to implement SET and GET content in one function >> effectively. I believe so static variables can be enough for 50%, but it >> is too limited. Postgres cannot to pass and work with references, so >> this C design can be too expensive. >> > > You can always accept a boolean that tells you if you're setting or just > returning. And there's probably some use cases where you don't even need to > expose the variable outside of the function. >
It is too simple and too like workaround :) I can do it this in plpgsql extension probably. > 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. Regards Pavel
