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