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

From Julien Rouhaud
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id 20210822120743.lvazjchtns5sezb2@nol
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Mark all GUC variable as PGDLLIMPORT  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Mark all GUC variable as PGDLLIMPORT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Aug 22, 2021 at 08:51:26PM +0900, Michael Paquier wrote:
> On Sun, Aug 22, 2021 at 04:10:33PM +0800, Julien Rouhaud wrote:
> > This topic has been raised multiple time over the years, and I don't see any
> > objection to add such an annotation at least for all GUC variables (either the
> > direct variables or the indirect variables set during the hook execution), so
> > PFA a patch that takes care of all the GUC.
> > 
> > I don't now if that's still an option at that point, but backporting to at
> > least pg14 if that patch is accepted would be quite helpful.
> 
> These are usually just applied on HEAD

Yeah but 14 isn't released yet, and this is a really low risk change.

> , 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.  Why treating Windows as a
second-class citizen, especially when any change can only be used a year after
someone complained?



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Next
From: Pavel Stehule
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT