Re: Mark all GUC variable as PGDLLIMPORT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Date: 2021-08-22 13:19:42
Message-ID: 2210220.1629638382@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Julien Rouhaud <rjuju123(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-08-22 13:22:43 Re: Spelling change in LLVM 14 API
Previous Message Thomas Munro 2021-08-22 12:54:35 Spelling change in LLVM 14 API