Re: Mark all GUC variable as PGDLLIMPORT
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2021-08-23T14:07:16Z
Lists: pgsql-hackers
On Sun, Aug 22, 2021 at 09:29:01PM +0800, Julien Rouhaud wrote: > On Sun, Aug 22, 2021 at 09:19:42AM -0400, Tom Lane wrote: > > > > 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. > > Then shouldn't we try to prevent direct access on all platforms rather than > only one? Agreed. If Julian says 99% of the non-export problems are GUCs, and we can just export them all, why not do it? We already export every global variable on Unix-like systems, and we have seen no downsides. -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
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