Hi, On 2022-09-10 15:04:59 -0400, Tom Lane wrote: > Here's a WIP stab at the project Andres mentioned [1] of splitting up > guc.c into smaller files.
Cool! > As things stand here, we have: > > 1. guc.c: the core GUC machinery. > 2. guc_tables.c: the data arrays, and some previously-exposed constant > tables. guc_tables.h can now be considered the associated header. > 3. guc_hooks.c: (most of) the per-variable check/assign/show hooks > that had been in guc.c. guc_hooks.h declares these. > > File sizes are like so: > > $ wc guc*c > 2629 9372 69467 guc-file.c > 7422 25136 202284 guc.c > 939 2693 22915 guc_hooks.c > 4877 13163 126769 guc_tables.c > 15867 50364 421435 total > $ size guc*o > text data bss dec hex filename > 13653 4 112 13769 35c9 guc-file.o > 54953 0 564 55517 d8dd guc.o > 6951 0 112 7063 1b97 guc_hooks.o > 43570 62998 216 106784 1a120 guc_tables.o A tad surprised by the text size of guc_tables.o - not that it is a problem, just seems a bit odd. > I'm fairly happy with the way things turned out in guc.c and > guc_tables.c, but I don't much like guc_hooks.c. I think instead of > creating such a file, what we should do is to shove most of those > functions into whatever module the GUC variable is associated with. +1. I think our associated habit of declaring externs in multiple .c files isn't great either. > Before proceeding further, I wanted to ask for comments on a design > choice that might be controversial. Even though I don't want to > invent guc_hooks.c, I think we *should* invent guc_hooks.h, and > consolidate all the GUC hook function declarations there. The > point would be to not have to #include guc.h in headers of unrelated > modules. This is similar to what we've done with utils/fmgrprotos.h, > though the motivation is different. I already moved a few declarations > from guc.h to there (and in consequence had to adjust #includes in > the modules defining those hooks), but there's a lot more to be done > if we apply that policy across the board. Does anybody think that's > a bad approach, or have a better one? Hm, I'm not opposed, the reasoning makes sense to me. How would this interact with the declaration of the variables underlying GUCs? Greetings, Andres Freund
