Re: proposal: schema PL session variables
От | Pavel Stehule |
---|---|
Тема | Re: proposal: schema PL session variables |
Дата | |
Msg-id | CAFj8pRAhK1UzDKvamHcLZL5ZGUcc3XrEyHN-MfvjJAShmHMZZQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: proposal: schema PL session variables (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: proposal: schema PL session variables
|
Список | pgsql-hackers |
2016-02-10 20:10 GMT+01:00 Jim Nasby <Jim.Nasby@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
В списке pgsql-hackers по дате отправления: