Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-05-07 10:29:36 -0400, Tom Lane wrote:
>> To my mind, we PGDLLEXPORT some variable only after deciding that yeah,
>> we're okay with having third-party modules touching that. Craig's
>> proposal is to remove human judgement from that process.
> It's just levelling the planefield between platforms. If I had an idea
> how I'd still like to just PGDDLIMPORT *all* 'export'ed variables on
> windows.
> The problem is that there's lot of variables which aren't exported and
> which we'll only discover after the release. Just look at what
> e.g. postgres_fdw needed. It's not particularly unlikely that others
> fdws need some of those as well. But they can't change the release at
> the same time.
[ shrug... ] That problem is uncorrelated with GUC status, however.
If that's your argument for a patch, then the patch should DLLEXPORT
*every single non-static variable*. Which is a discussion we've already
had, and rejected.
I'd not be against an automatic mechanism for that, and indeed put
considerable work into trying to make it happen a few months ago. But
I'll resist wholesale cluttering of the source code with those markers.
As long as we have to have them, I think we should use them in the way
I outlined, that we mark only variables that are "considered okay to
access". In fact, GUCs are exactly the *last* variables that should get
marked that way automatically, because so many of them are global only
because of the need for guc.c to communicate with the owning module,
not because we want anything else touching them.
regards, tom lane