Re: Mark all GUC variable as PGDLLIMPORT

On Sun, 22 Aug 2021 at 21:29, Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:

> On Sun, Aug 22, 2021 at 09:19:42AM -0400, Tom Lane wrote:
> >
> > Uh, no, it's exactly *not* clear. There are a lot of GUCs that are only
> > of interest to particular subsystems. I do not see why being a GUC makes
> > something automatically more interesting than any other global variable.
> > Usually, the fact that one is global is only so the GUC machinery itself
> > can get at it, otherwise it'd be static in the owning module.
> >
> > As for "extensions should be able to get at the values", the GUC
> machinery
> > already provides uniform mechanisms for doing that safely. Direct access
> > to the variable's internal value would be unsafe in many cases.
>
> Then shouldn't we try to prevent direct access on all platforms rather than
> only one?
>

Yes. That's what I think we should be doing if we're not going to
PGDLLIMPORT them all.

The current API is painful because it round-trips via a text
representation. We'd at least want some kind of

GetConfigOptionBool(...)
GetConfigOptionEnum(...)

etc.

I don't understand the objection to marking them all PGDLLIMPORT anyway
though.

Any pretense that Pg has any sort of public/private API divide is pure
fantasy. Whether things are static or not, in public headers or "internal"
headers, etc, is nearly random. We have absolutely no API surface control
such as __attribute__((visibility("hidden"))) annotations, and proposals to
add them have been soundly rejected in the past.

If we have a defined API, where is it defined and annotated?

If we don't, then Windows being different and incompatible is a bug, and
that bug should be fixed.