Re: Mark all GUC variable as PGDLLIMPORT
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2021-08-22T13:19:42Z
Lists: pgsql-hackers
Julien Rouhaud <rjuju123@gmail.com> writes: > On Sun, Aug 22, 2021 at 08:51:26PM +0900, Michael Paquier wrote: >> ... and on a parameter-basis based >> on requests from extension authors. If you wish to make your >> extensions able to work on Windows, that's a good idea, but I would >> recommend to limit this exercise to what's really necessary for your >> purpose. > I disagree. For random global variables I agree that we shouldn't mark them > all blindly, but for GUCs it's pretty clear that they're intended to be > accessible from any caller, including extensions. Uh, no, it's exactly *not* clear. There are a lot of GUCs that are only of interest to particular subsystems. I do not see why being a GUC makes something automatically more interesting than any other global variable. Usually, the fact that one is global is only so the GUC machinery itself can get at it, otherwise it'd be static in the owning module. As for "extensions should be able to get at the values", the GUC machinery already provides uniform mechanisms for doing that safely. Direct access to the variable's internal value would be unsafe in many cases. 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