Re: Mark all GUC variable as PGDLLIMPORT

Robert Haas <robertmhaas@gmail.com> writes:
> Hmm, I guess I'd need to know who those people are in order to be able
> to review their comments. I don't *like* the extra notational cruft,
> but applying it inconsistently isn't better than being consistent. As
> I see it, we have four choices: (1) apply PGDLLIMPORT markings
> relatively broadly so that people can get extensions to work on
> Windows, (2) continue to apply them inconsistently, thus slightly
> reducing notational clutter at the cost of breaking lots of extensions
> on Windows, (3) put some complex system in place like what Chapman
> proposes and get all extension authors to adopt it, and (4) remove the
> Windows port. To the best of my current knowledge, everyone other than
> you prefers (1), you prefer (2) or (4), and (3) is an attempt at
> compromise that is nobody's first choice.

I think you are attributing straw-man positions to me.  What I'd actually
*like* is some solution that has the effect of (1) without having to mark
up our code with a bunch of Microsoft-isms.  However I don't know how to
do that, and I do agree that (2), (3), and (4) are not better than (1).

There are some technical issues though:

* AFAICS, the patch of record doesn't actually do (1), it does something
else that adds yet more new notation.  The cfbot says it fails, too.

* If we institute a policy that all GUCs should be PGDLLIMPORT'd,
how will we enforce that new patches follow that?  I don't want to be
endlessly going back and adding forgotten PGDLLIMPORT markers.

* There's a moderately sizable subset of GUCs where the underlying
variable is not visible at all because it's static in guc.c.
Typically this is because that variable is only used for display
and there's an assign hook that stores the real data somewhere else.
I suppose what we want in such cases is for the "somewhere else"
to be PGDLLIMPORT'd, but in a lot of cases those variables are also
static in some other module.  Does this proposal include exporting
variables that currently aren't visible to extensions at all?
I'm a little resistant to that.  I can buy making sure that Windows
has a level playing field, but that's as far as I want to go.

			regards, tom lane