Re: Extension upgrade and GUCs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Extension upgrade and GUCs
Date
Msg-id 17983.1440080464@sss.pgh.pa.us
Whole thread Raw
In response to Re: Extension upgrade and GUCs  (Paul Ramsey <pramsey@cleverelephant.ca>)
Responses Re: Extension upgrade and GUCs  (Paul Ramsey <pramsey@cleverelephant.ca>)
List pgsql-hackers
Paul Ramsey <pramsey@cleverelephant.ca> writes:
> On August 20, 2015 at 2:17:31 AM, Simon Riggs (simon@2ndquadrant.com(mailto:simon@2ndquadrant.com)) wrote:
>> 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
wherethe variable hadn’t been created yet…, since one of the problems is knowing if/to-what-extent a custom variable
hasalready been defined).
 

I'm not sure that the situation you describe can be expected to work
reliably; the problems are far wider than just GUC variables.  If two
different .so's are exposing broadly the same set of C function names,
how can we be sure which one will get called by the dynamic linker?
Isn't it likely that we'd end up continuing to call some functions
out of the old .so, probably leading to disaster?

I don't necessarily object to providing some solution for GUCs, but
I think first we need to question whether that isn't just the tip of
a large iceberg.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Supporting fallback RADIUS server(s)
Next
From: Magnus Hagander
Date:
Subject: Re: Supporting fallback RADIUS server(s)