From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Splitting up guc.c
Date: Sat, 10 Sep 2022 15:23:40 -0400
Message-ID: <597492.1662837820@sss.pgh.pa.us> (raw)
In-Reply-To: <20220910191533.4d7xib46m62sf2mv@awork3.anarazel.de>
References: <587607.1662836699@sss.pgh.pa.us>
<20220910191533.4d7xib46m62sf2mv@awork3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> On 2022-09-10 15:04:59 -0400, Tom Lane wrote:
>> $ 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.
There's a pretty fair number of constant tables that got moved to there.
Not to mention all the constant strings.
>> 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?
I'd still declare the variables as we do now, ie just straightforwardly
export them from the associated modules. Since they're all of native
C types, they don't cause any inclusion-footprint issues. We could move
their declarations to a common file I guess, but I don't see any benefit.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, pgsql-hackers@lists.postgresql.org
Subject: Re: Splitting up guc.c
In-Reply-To: <597492.1662837820@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox