Re: Mark all GUC variable as PGDLLIMPORT

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Mark all GUC variable as PGDLLIMPORT
Дата
Msg-id CA+Tgmob=MAyHcPh8iTOg5i-S+UYMjxgJ8nrWpPK0YNULH85b2g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Mark all GUC variable as PGDLLIMPORT  (Chapman Flack <chap@anastigmatix.net>)
Ответы Re: Mark all GUC variable as PGDLLIMPORT  (Chapman Flack <chap@anastigmatix.net>)
Re: Mark all GUC variable as PGDLLIMPORT  (Craig Ringer <craig.ringer@enterprisedb.com>)
Список pgsql-hackers
On Tue, Aug 24, 2021 at 2:52 PM Chapman Flack <chap@anastigmatix.net> wrote:
> I don't think that's true of the second proposal in [0]. I don't foresee
> a noticeable runtime cost unless there is a plausible workload that
> involves very frequent updates to GUC settings that are also of interest
> to a bunch of extensions. Maybe I'll take a stab at a POC.

I'm not sure I fully understand that proposal, but I find it hard to
believe that we would seriously consider replacing every direct GUC
reference in the backend with something that goes through an API. Even
if didn't hurt performance, I think it would uglify the code a whole
lot.

And as Peter says, if we're not going to do that, then it's not clear
why extensions should have to.

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



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: .ready and .done files considered harmful
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: Mark all GUC variable as PGDLLIMPORT