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.



Reply via email to