Re: Splitting up guc.c - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Splitting up guc.c
Date
Msg-id 20220912193928.wgrccx4b4k3solpu@awork3.anarazel.de
Whole thread Raw
In response to Re: Splitting up guc.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2022-09-11 18:31:41 -0400, Tom Lane wrote:
> Here's a v3 that gets rid of guc_hooks.c in favor of moving the
> hook functions to related modules (though some did end up in
> variables.c for lack of a better idea).

- 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?

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

- Are all those includes in guc_tables.c still necessary? I'd have assumed
  that more should be obsoleted by the introduction of guc_hooks.h? Although I
  guess many are just there for the variable's declaration?

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



> I think this is code-complete at this point.  I'd like to not
> sit on it too long, because it'll inevitably get side-swiped
> by additions of new GUCs.  On the other hand, pushing it in
> the middle of a CF would presumably break other people's patches.
> Maybe push it at the end of this CF, to give people a month to
> rebase anything that's affected?

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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: PostgreSQL 15 release announcement draft
Next
From: Tom Lane
Date:
Subject: Re: Splitting up guc.c