Re: Extension upgrade and GUCs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Extension upgrade and GUCs
Date: 2015-08-20 14:21:04
Message-ID: 17983.1440080464@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Paul Ramsey <pramsey(at)cleverelephant(dot)ca> writes:
> On August 20, 2015 at 2:17:31 AM, Simon Riggs (simon(at)2ndquadrant(dot)com(mailto:simon(at)2ndquadrant(dot)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 where the variable hadnt been created yet, since one of the problems is knowing if/to-what-extent a custom variable has already 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2015-08-20 14:25:27 Re: Supporting fallback RADIUS server(s)
Previous Message Tom Lane 2015-08-20 14:16:12 Re: Supporting fallback RADIUS server(s)