Here's a WIP stab at the project Andres mentioned [1] of splitting up guc.c into smaller files. 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 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. (Perhaps commands/variable.c could absorb any stragglers that lack a better home.) I made a start at that for wal_consistency_checking and the syslog parameters, but haven't gone further yet. 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? BTW, this is more or less orthogonal to my other GUC patch at [2], although both lead to the conclusion that we need to export guc_malloc and friends. regards, tom lane [1] https://www.postgresql.org/message-id/20220905233233.jhcu5jqsrtosmgh5%40awork3.anarazel.de [2] https://www.postgresql.org/message-id/flat/2982579.1662416866%40sss.pgh.pa.us
split-up-guc-code-1.patch.gz
Description: split-up-guc-code-1.patch.gz