From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Splitting up guc.c
Date: Mon, 12 Sep 2022 15:46:10 -0400
Message-ID: <1771845.1663011970@sss.pgh.pa.us> (raw)
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>
Andres Freund <andres@anarazel.de> writes:
> - a bit worried that in_hot_standby will be confusing due vs InHotStandby. 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 function
> 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 rename.
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
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, michael@paquier.xyz, pgsql-hackers@lists.postgresql.org
Subject: Re: Splitting up guc.c
In-Reply-To: <1771845.1663011970@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