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
