Re: Mark all GUC variable as PGDLLIMPORT

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: Mark all GUC variable as PGDLLIMPORT
Дата
Msg-id CAFj8pRCkKm-85z4YzNUV3cDVfspSWe6VbDv=B18QeBsNzoV2Lw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Mark all GUC variable as PGDLLIMPORT  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Mark all GUC variable as PGDLLIMPORT
Список 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 по дате отправления:

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