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

From Pavel Stehule
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id CAFj8pRCkKm-85z4YzNUV3cDVfspSWe6VbDv=B18QeBsNzoV2Lw@mail.gmail.com
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Mark all GUC variable as PGDLLIMPORT  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers


ne 22. 8. 2021 v 14:08 odesílatel Julien Rouhaud <rjuju123@gmail.com> napsal:
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?

I had few problems with access with these variables too when I worked on orafce.

Is true, so it increases differences between Windows and Unix, and fixing these issues is not fun work. On the other hand, maybe direct access to these variables from extensions is an antipattern, and we should use a direct function call API and functions current_setting and set_config. The overhead is usually not too big.



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT
Next
From: Julien Rouhaud
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT