On August 20, 2015 at 2:17:31 AM, Simon Riggs (simon@2ndquadrant.com(mailto:simon@2ndquadrant.com)) wrote: > On 18 August 2015 at 21:03, Paul Ramsey wrote: > > > So I need a way to either (a) notice when I already have a (old) copy > > of the library loaded and avoid trying to setup the GUC in that case > > or (b) set-up the GUC in a somewhat less brittle way than > > DefineCustomStringVariable() allows, something that can overwrite > > things instead of just erroring out. > > Are you trying to preserve the in-memory state across upgrade as well? It sounds unlikely we can support that directly in the general case.
I’m not sure what you mean by this.
The value of the global variable can't be maintained across upgrade.
> Sounds like we need RedefineCustomStringVariable()
Yes, if that had existed we would not have had any problems (as long as it delegated back to Define..() in the case where the variable hadn’t been created yet…, since one of the problems is knowing if/to-what-extent a custom variable has already been defined).
We do now have a fix, which involved copying about 100 lines of core code (find_option, guc_var_compare, guc_name_compare) up, that does a low level search to see if there is a config_generic for a particular variable name, and if so whether it’s a placeholder or not. The presence of a non-placeholding definition is used as a “uh oh, there’s already a library in here” warning which keeps us from re-defining the variable and causing trouble.
I'm sure we all agree PostGIS is an important use case. Core is the right place to put such code.
Please submit a patch that does that - better than someone else trying to get it right for you. Thanks
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
