Re: Mark all GUC variable as PGDLLIMPORT

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Mark all GUC variable as PGDLLIMPORT
Дата
Msg-id 2210220.1629638382@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Mark all GUC variable as PGDLLIMPORT  (Julien Rouhaud <rjuju123@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Spelling change in LLVM 14 API
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Spelling change in LLVM 14 API