>> 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.



> --
> 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

Reply via email to