Re: Mark all GUC variable as PGDLLIMPORT

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Mark all GUC variable as PGDLLIMPORT
Дата
Msg-id CA+TgmoY8Z9PJHeFp6wWBXG0ZcdV_22edbn-qxybNmb3jRR-a6A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Mark all GUC variable as PGDLLIMPORT  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Mark all GUC variable as PGDLLIMPORT
Re: Mark all GUC variable as PGDLLIMPORT
Список pgsql-hackers
On Mon, Aug 23, 2021 at 11:40 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> In that case, why not improve the API with functions that return the
> values in some native datatype?  For scalars with native C types (int,
> floats, Boolean etc) this is easy enough; I bet it'll solve 99% of the
> problems or more.

Sure, but ... why bother?

The entire argument rests on the presumption that there is some harm
being done by people accessing the values directly, but I don't think
that's true. And, if it were true, it seems likely that this proposed
API would have the exact same problem, because it would let people do
exactly the same thing. And, going through this proposed API would
still be significantly more expensive than just accessing the bare
variables, because you'd at least have to do some kind of lookup based
on the GUC name to find the corresponding variable. It's just a
solution in search of a problem.

Nothing bad happens when people write extensions that access GUC
variables directly. It works totally, completely fine. Except on
Windows.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: very long record lines in expanded psql output
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Delegating superuser tasks to new security roles (Was: Granting control of SUSET gucs to non-superusers)