Re: Mark all GUC variable as PGDLLIMPORT - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id CAGRY4nwHWgeR7LEV49MdYb_nOC_LxuJyLc_AMKPLFUT0os-cTw@mail.gmail.com
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Julien Rouhaud <rjuju123@gmail.com>)
List 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.

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Next
From: Masahiko Sawada
Date:
Subject: Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN