Re: Mark all GUC variable as PGDLLIMPORT - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id 546211.1629902474@sss.pgh.pa.us
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Mark all GUC variable as PGDLLIMPORT  (Magnus Hagander <magnus@hagander.net>)
Re: Mark all GUC variable as PGDLLIMPORT  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Aug 25, 2021 at 4:06 PM Robert Haas <robertmhaas@gmail.com> wrote:
>> It does tend to be controversial, but I think that's basically only
>> because Tom Lane has reservations about it. I think if Tom dropped his
>> opposition to this, nobody else would really care. And I think that
>> would be a good thing for the project.

> But in particular, both on that argument, and on the general
> maintenance argument, I have a very hard time seeing how exporting the
> GUC variables would be any worse than exporting the many hundreds of
> functions we already export.

My beef about it has nothing to do with binary-size concerns, although
that is an interesting angle.  (I wonder whether marking a variable
PGDLLIMPORT has any negative effect on the cost of accessing it from
within the core code?)  Rather, I'm unhappy with spreading even more
Microsoft-droppings all over our source.  If there were some way to
just do this automatically for all global variables without any source
changes, I'd be content with that.  That would *really* make the
platforms more nearly equivalent.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Next
From: Magnus Hagander
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT