Re: Mark all GUC variable as PGDLLIMPORT

On Tue, 24 Aug 2021 at 05:08, Chapman Flack <chap(at)anastigmatix(dot)net> wrote:

> On 08/23/21 14:30, Robert Haas wrote:
> > it seems likely that this proposed
> > API would have the exact same problem, because it would let people do
> > exactly the same thing. And, going through this proposed API would
> > still be significantly more expensive than just accessing the bare
> > variables, because you'd at least have to do some kind of lookup based
> > on the GUC name
>
> I think the API ideas in [0] would not let people do exactly the same
> thing.
>
> They would avoid exposing the bare variables to overwrite. Not that
> there has been any plague of extensions going and overwriting GUCs,
> but I think in some messages on this thread I detected a sense that
> in principle it's better if an API precludes it, and that makes sense
> to me.
>
> The second idea also avoids the expense of name-based lookup (except once
> at extension initialization), and in fact minimizes the cost of obtaining
> the current value when needed, by slightly increasing the infrequent cost
> of updating values.
>

I'd be generally in favour of something that reduced our reliance on the
current chaotic and inconsistent jumble of globals which are a semi-random
combination of compilation-unit-scoped, globally-scoped-except-on-Windows
and globally scoped.

Tackling GUCs would be a good start. Especially given the number of GUCs
where the actual GUC value isn't the state that anyone should be
interacting with directly since a hook maintains the "real" state derived
from the GUC storage.

And preventing direct writes to GUCs seems like a clearly correct thing to
do.

Some consideration of performance would be important for some of the hotter
GUCs, of course, but most extensions won't be hammering most GUC access a
lot.