From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Subject: Re: Splitting up guc.c
In-reply-to: <20220912193928.wgrccx4b4k3solpu@awork3.anarazel.de>
References: <587607.1662836699@sss.pgh.pa.us> <Yx0vHEBXwcUggZYK@paquier.xyz>
 <666417.1662862120@sss.pgh.pa.us> <925946.1662918775@sss.pgh.pa.us>
 <1305798.1662935501@sss.pgh.pa.us>
 <20220912193928.wgrccx4b4k3solpu@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 12 Sep 2022 12:39:28 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1771844.1663011970.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 12 Sep 2022 15:46:10 -0400
Message-ID: <1771845.1663011970@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1771845.1663011970%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> - a bit worried that in_hot_standby will be confusing due vs InHotStandb=
y. I
>   wonder if we could perhaps get rid of an underlying variable in cases =
where
>   we really just need the GUC entry to trigger the show hook?

Yeah, that worried me too.  We do need the variable because guc.c checks
it directly, but let's use a less confusing name.  in_hot_standby_guc,
maybe?

> - perhaps too annoying, but it'd be easier to review this if the functio=
n
>   renaming were done in a preparatory patch

There were only a couple that I renamed, and I don't think any of them
should be directly referenced by anything else.

> - Are all those includes in guc_tables.c still necessary?

The ones that are still there are necessary.  I believe they're mostly
pulling in variables that are GUC targets.

> - It's a bit depressing that the GUC arrays aren't const, . But I guess =
that's
>   better fixed separately.

Dunno that it'd be helpful, unless we separate the variable and constant
parts of the structs.

> I think this is localized enough that asking people to manually resolve =
a
> conflict around adding a GUC entry wouldn't be asking for that much. And=
 I
> think plenty changes might be automatically resolvable, despite the rena=
me.

I wonder whether git will be able to figure out that this is mostly a
code move.  I would expect so for a straight file rename, but will that
work when we're splitting the file 3 ways?

			regards, tom lane