Re: Mark all GUC variable as PGDLLIMPORT

On Mon, Feb 14, 2022 at 12:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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).

OK, that sounds like we might be making some progress toward a useful agreement.

> 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.

That sounds like a problem. Should be fixable.

> * 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.

It seems to me that it would be no different from bumping catversion
or updating nodefuncs.c: yes, it will get forgotten sometimes, but
hopefully people will mostly get used to it just like they do with
dozens of other PG-specific coding rules. I don't see that it's likely
to generate more than a handful of commits per year, so it doesn't
really seem worth worrying about to me, but YMMV. Maybe it's possible
to write a perl script to verify it, although it seems like it might
be complicated to code that up.

> * 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.

I can live with that. If someone complains about those variables being
static-to-file instead of globally visible, we can address that
complaint on its merits when it is presented.

An alternative rule which would dodge that particular issue would be
to just slap PGDLLIMPORT on every global variable in every header
file. That would arguably be a simpler rule, though it means even more
PGDLLIMPORT declarations floating around.

-- 
Robert Haas
EDB: http://www.enterprisedb.com