On 2/10/16 11:25 AM, Pavel Stehule wrote:
Oh, and I suggest we call them SESSION variables rather than SCHEMA
variables, to reinforce the idea of how long the values in the
variables live. A session variable is in a sense a 1x1 temp table,
whose definition persists across sessions but whose value does not.
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.)
--
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
