On 20 August 2015 at 13:21, Paul Ramsey <pram...@cleverelephant.ca> wrote:
> On August 20, 2015 at 2:17:31 AM, Simon Riggs (si...@2ndquadrant.com > (mailto:si...@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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
