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