Re: Mark all GUC variable as PGDLLIMPORT

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Mark all GUC variable as PGDLLIMPORT
Дата
Msg-id 107477.1629728104@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Mark all GUC variable as PGDLLIMPORT  (Julien Rouhaud <rjuju123@gmail.com>)
Ответы Re: Mark all GUC variable as PGDLLIMPORT  (Julien Rouhaud <rjuju123@gmail.com>)
Re: Mark all GUC variable as PGDLLIMPORT  (Robert Haas <robertmhaas@gmail.com>)
Re: Mark all GUC variable as PGDLLIMPORT  (Craig Ringer <craig.ringer@enterprisedb.com>)
Список pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Sun, Aug 22, 2021 at 09:29:01PM +0800, Julien Rouhaud wrote:
>> Then shouldn't we try to prevent direct access on all platforms rather than
>> only one?

> Agreed.  If Julian says 99% of the non-export problems are GUCs, and we
> can just export them all, why not do it?  We already export every global
> variable on Unix-like systems, and we have seen no downsides.

By that argument, *every* globally-visible variable should be marked
PGDLLIMPORT.  But the mere fact that two backend .c files need to access
some variable doesn't mean that we want any random bit of code doing so.

And yes, I absolutely would prohibit extensions from accessing many
of them, if there were a reasonable way to do it.  It would be a good
start towards establishing a defined API for extensions.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Queries that should be canceled will get stuck on secure_write function
Следующее
От: vignesh C
Дата:
Сообщение: Re: Added schema level support for publication.