On 2/10/16 1:17 PM, Pavel Stehule wrote:

2016-02-10 20:10 GMT+01:00 Jim Nasby <jim.na...@bluetreble.com

    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

It is too simple and too like workaround :) I can do it this in plpgsql
extension probably.

I think it's something people will definitely want. If we don't have it, then they're going to be using schema variables as a work-around because they can't do a private static variable inside a single 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.

My target is not 9.6 - next commitfest will be full - finishing multi
CPU queries, logical replication, .. and I have still three opened
patches. But if we find a agreement in this spring, I can implement it
in summer, and it can be in upstream in early 9.7 commitfest. I know,
this topic is difficult, so have to start it now.

Sure. I think it would be useful to have a wiki page with info as it gets ironed out. A good starting point would be use cases. One that I don't think has been considered is different extensions adding/using different schema variables. Questions like should extension A have direct access to variables for extension B.
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:

Reply via email to