>> I didn't propose SESSION variables - now there are some workarounds how >> to anybody can emulate it, so this feature can wait. What we need is >> safe session variables with limited access. And the border can be >> defined by schema scope. So the keyword SCHEMA has sense, and it is >> necessary. >> > > 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. Regards Pavel > > -- > Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX > Experts in Analytics, Data Architecture and PostgreSQL > Data in Trouble? Get it in Treble! http://BlueTreble.com >
