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
Date: Sat, 10 Sep 2022 22:08:40 -0400
Message-ID: <666417.1662862120@sss.pgh.pa.us> (raw)
In-Reply-To: <Yx0vHEBXwcUggZYK@paquier.xyz>
References: <587607.1662836699@sss.pgh.pa.us>
<Yx0vHEBXwcUggZYK@paquier.xyz>
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
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, michael@paquier.xyz, andres@anarazel.de
Subject: Re: Splitting up guc.c
In-Reply-To: <666417.1662862120@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