Re: PGDLLEXPORTing all GUCs?

On Wed, May 7, 2014 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

I don't accept this argument.  In EnterpriseDB's Advanced Server fork
of PostgreSQL, we've marked a bunch of extra things PGDLLEXPORT
precisely because we have external modules that need access to them.
Of course, what that means is that when PostgreSQL changes things
around in a future release, we have to go revise those external
modules as well.  However, that just doesn't happen often enough to
actually pose a significant problem for us.  It's not really accurate
to think that people are only going to rely on the things that we
choose to PGDLLEXPORT.  It's more accurate to think that when we don't
mark things PGDLLEXPORT, we're forcing people to decide between (1)
giving up on writing their extension, (2) having that extension not
work on Windows, (3) submitting a patch to add a PGDLLEXPORT marking
and waiting an entire release cycle for that to go G.A., and then
still not being able to support older versions, or (4) forking
PostgreSQL.  That's an unappealing list of options.

I would not go so far as to say that we should PGDLLEXPORT absolutely
every non-static variable.  But I think adding those markings to every
GUC we've got is perfectly reasonable.  I am quite sure that the
2ndQuadrant folks know that they'll be on the hook to update any code
they write that uses those variables if and when a future version of
PostgreSQL whacks things around.  But that's not a new problem - the
same thing happens when a function signature changes, or when a
variable that does happen to have a PGDLLEXPORT marking changes.  And
at least in my experience it's also not a large problem.  The amount
of time EnterpriseDB spends updating our (large!) amount of
proprietary code in response to such changes is a small percentage of
our overall development time.

Enabling extensibility is a far more important goal than keeping
people from committing to interfaces that may change in the future,
especially since the latter is a losing battle anyway.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company