Re: Splitting up guc.c
Tom Lane <tgl@sss.pgh.pa.us>
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
Date: 2022-09-12T19:46:10Z
Lists: pgsql-hackers
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
Commits
-
Split up guc.c for better build speed and ease of maintenance.
- 0a20ff54f5e6 16.0 landed