From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
cc: pgsql-hackers@lists.postgresql.org, Andres Freund <andres@anarazel.de>
Subject: Re: Splitting up guc.c
In-reply-to: <Yx0vHEBXwcUggZYK@paquier.xyz>
References: <587607.1662836699@sss.pgh.pa.us> <Yx0vHEBXwcUggZYK@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael@paquier.xyz>
	message dated "Sun, 11 Sep 2022 09:43:08 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <666416.1662862120.1@sss.pgh.pa.us>
Date: Sat, 10 Sep 2022 22:08:40 -0400
Message-ID: <666417.1662862120@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/666417.1662862120%40sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael@paquier.xyz> writes:
> One part that I have found a bit strange lately about guc.c is that we
> have mix the core machinery with the SQL-callable parts.  What do you
> think about the addition of a gucfuncs.c in src/backend/utils/adt/ to
> split things a bit more?

I might be wrong, but I think the SQL-callable stuff makes use
of some APIs that are currently private in guc.c.  So we'd have
to expose more API to make that possible.  Maybe that wouldn't
be a bad thing, but it seems to be getting beyond the original
idea here.  (Note I already had to expose find_option() in
order to get the wal_consistency_checking stuff moved out.)
It's not clear to me that "move the SQL-callable stuff" will
end with a nice API boundary.

			regards, tom lane