Re: Mark all GUC variable as PGDLLIMPORT
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Magnus Hagander <magnus@hagander.net>
Cc: Robert Haas <robertmhaas@gmail.com>,
Chapman Flack <chap@anastigmatix.net>,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
Julien Rouhaud <rjuju123@gmail.com>, Bruce Momjian <bruce@momjian.us>,
Michael Paquier <michael@paquier.xyz>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-08-25T14:41:14Z
Lists: 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
Commits
-
Remove PGDLLIMPORT marker from __pg_log_level
- 8d3341266508 15.0 landed
-
Mark a few 'bbsink' related functions / variables static.
- b5f44225b833 15.0 landed
-
Add some missing PGDLLIMPORT markings
- 5edeb574285e 15.0 landed
-
Apply PGDLLIMPORT markings broadly.
- 8ec569479fc2 15.0 landed
-
Helper script to apply PGDLLIMPORT markings.
- 80900d469091 15.0 landed
-
Simplify declaring variables exported from libpgcommon and libpgport.
- e04a8059a74c 15.0 cited