Re: Splitting up guc.c
От | Andres Freund |
---|---|
Тема | Re: Splitting up guc.c |
Дата | |
Msg-id | 20220912193928.wgrccx4b4k3solpu@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Splitting up guc.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Hi, On 2022-09-11 18:31:41 -0400, Tom Lane wrote: > Here's a v3 that gets rid of guc_hooks.c in favor of moving the > hook functions to related modules (though some did end up in > variables.c for lack of a better idea). - a bit worried that in_hot_standby will be confusing due vs InHotStandby. I wonder if we could perhaps get rid of an underlying variable in cases where we really just need the GUC entry to trigger the show hook? - perhaps too annoying, but it'd be easier to review this if the function renaming were done in a preparatory patch - Are all those includes in guc_tables.c still necessary? I'd have assumed that more should be obsoleted by the introduction of guc_hooks.h? Although I guess many are just there for the variable's declaration? - It's a bit depressing that the GUC arrays aren't const, . But I guess that's better fixed separately. > I think this is code-complete at this point. I'd like to not > sit on it too long, because it'll inevitably get side-swiped > by additions of new GUCs. On the other hand, pushing it in > the middle of a CF would presumably break other people's patches. > Maybe push it at the end of this CF, to give people a month to > rebase anything that's affected? I think this is localized enough that asking people to manually resolve a conflict around adding a GUC entry wouldn't be asking for that much. And I think plenty changes might be automatically resolvable, despite the rename. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: