Re: Splitting up guc.c

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