From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?= <ilmari@ilmari.org>,
        Andres Freund <andres@anarazel.de>,
        Michael Paquier <michael@paquier.xyz>,
        pgsql-hackers@lists.postgresql.org
Subject: Re: Splitting up guc.c
In-reply-to: <20220913091000.l4dam6w5euja3pua@alvherre.pgsql>
References: <20220913091000.l4dam6w5euja3pua@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Tue, 13 Sep 2022 11:10:00 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2038317.1663077955.1@sss.pgh.pa.us>
Date: Tue, 13 Sep 2022 10:05:55 -0400
Message-ID: <2038318.1663077955@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2038318.1663077955%40sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2022-Sep-12, Tom Lane wrote:
>> Yeah, I suspect people will have to manually reapply any changes in
>> the GUC tables to guc_tables.c.  That'll be the same amount of work
>> for them whenever we commit this patch (unless theirs lands first,
>> in which case I have to deal with it).  The issue I think is
>> whether it's politer to make that happen during a CF or between
>> CFs.

> Personally I would prefer that this kind of thing is done quickly rather
> than delay it to some uncertain future.  That way I can deal with it
> straight ahead rather than living with the anxiety that it will land
> later and I will have to deal with it then.  I see no benefit in
> waiting.

Fair enough.  I'm also not looking forward to having to rebase my
patch over anybody else's GUC changes -- even just a new GUC would
invalidate a thousand-line diff hunk, and I doubt that "git apply"
would deal with that very helpfully.  I'll go ahead and get this
pushed.

			regards, tom lane