Re: proposal: schema PL session variables

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Marko Tiikkaja <marko(at)joh(dot)to>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <obartunov(at)gmail(dot)com>
Subject: Re: proposal: schema PL session variables
Date: 2016-02-10 19:17:22
Message-ID: CAFj8pRAhK1UzDKvamHcLZL5ZGUcc3XrEyHN-MfvjJAShmHMZZQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2016-02-10 20:10 GMT+01:00 Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-02-10 19:25:44 Re: proposal: schema PL session variables
Previous Message Jim Nasby 2016-02-10 19:16:07 Re: proposal: PL/Pythonu - function ereport