Re: Mark all GUC variable as PGDLLIMPORT
Craig Ringer <craig.ringer@enterprisedb.com>
From: Craig Ringer <craig.ringer@enterprisedb.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <bruce@momjian.us>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-08-24T05:49:08Z
Lists: pgsql-hackers
On Mon, 23 Aug 2021 at 22:45, Julien Rouhaud <rjuju123@gmail.com> wrote: > On Mon, Aug 23, 2021 at 10:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > > Bruce Momjian <bruce@momjian.us> writes: > > > On Mon, Aug 23, 2021 at 10:15:04AM -0400, Tom Lane wrote: > > >> By that argument, *every* globally-visible variable should be marked > > >> PGDLLIMPORT. But the mere fact that two backend .c files need to > access > > > > > No, Julien says 99% need only the GUCs, so that is not the argument I > am > > > making. > > > > That's a claim unbacked by any evidence that I've seen. More to > > the point, we already have a mechanism that extensions can/should > > use to read and write GUC settings, and it's not direct access. > > I clearly didn't try all single extension available out there. It's > excessively annoying to compile extensions on Windows, and also I > don't have a lot of dependencies installed so there are some that I > wasn't able to test since I'm lacking some other lib and given my > absolute lack of knowledge of that platform I didn't spent time trying > to install those. > > Plenty of them are closed too. While that's not the Pg community's problem, as such, it'd be nice not to arbitrarily break them all for no actual benefit.
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