Horton

Re: Mark all GUC variable as PGDLLIMPORT

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Chapman Flack <chap@anastigmatix.net>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Julien Rouhaud <rjuju123@gmail.com>, Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-08-24T19:12:45Z
Lists: pgsql-hackers 
On Tue, Aug 24, 2021 at 2:52 PM Chapman Flack <chap@anastigmatix.net> wrote:
> I don't think that's true of the second proposal in [0]. I don't foresee
> a noticeable runtime cost unless there is a plausible workload that
> involves very frequent updates to GUC settings that are also of interest
> to a bunch of extensions. Maybe I'll take a stab at a POC.

I'm not sure I fully understand that proposal, but I find it hard to
believe that we would seriously consider replacing every direct GUC
reference in the backend with something that goes through an API. Even
if didn't hurt performance, I think it would uglify the code a whole
lot.

And as Peter says, if we're not going to do that, then it's not clear
why extensions should have to.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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.