2017-09-19 20:37 GMT+02:00 Robert Haas <robertmh...@gmail.com>: > On Tue, Sep 19, 2017 at 12:45 PM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > >> You can already set a GUC with function scope. I'm not getting your > >> point. > > > > yes, it is true. But implementation of #option is limited to PLpgSQL - so > > there is not any too much questions - GUC is global - there is lot of > > points: > > > > * what is correct impact on PREPARE > > * what is correct impact on EXECUTE > > * what should be done if this GUC is changed .. > > For better or for worse, as a project we've settled on GUCs as a way > to control behavior. I think it makes more sense to try to apply that > option to new behaviors we want to control than to invent some new > system. >
I have nothing against GUC generally - just in this case, I have knowleadge what is expected behave in plpgsql environment and I miss this knowleadge else where, so I am thinking be good start just for plpgsql (where this issue is mentioned often). The some plpgsql limitted implementation is not barier against any another implementation. > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
