Re: Mark all GUC variable as PGDLLIMPORT

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: Mark all GUC variable as PGDLLIMPORT
Дата
Msg-id 20210822120743.lvazjchtns5sezb2@nol
обсуждение исходный текст
Ответ на Re: Mark all GUC variable as PGDLLIMPORT  (Michael Paquier <michael@paquier.xyz>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Mark all GUC variable as PGDLLIMPORT
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Mark all GUC variable as PGDLLIMPORT