Horton

Re: Mark all GUC variable as PGDLLIMPORT

Julien Rouhaud <rjuju123@gmail.com>

View thread View on postgr.es
From: Julien Rouhaud <rjuju123@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2021-08-22T13:29:01Z
Lists: pgsql-hackers 
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?

Commits

  1. Remove PGDLLIMPORT marker from __pg_log_level

  2. Mark a few 'bbsink' related functions / variables static.

  3. Add some missing PGDLLIMPORT markings

  4. Apply PGDLLIMPORT markings broadly.

  5. Helper script to apply PGDLLIMPORT markings.

  6. Simplify declaring variables exported from libpgcommon and libpgport.