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

From Tom Lane
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id 2210220.1629638382@sss.pgh.pa.us
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
Julien Rouhaud <rjuju123@gmail.com> writes:
> On Sun, Aug 22, 2021 at 08:51:26PM +0900, Michael Paquier wrote:
>> ... 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.

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Spelling change in LLVM 14 API
Next
From: Tom Lane
Date:
Subject: Re: Spelling change in LLVM 14 API