Re: Splitting up guc.c

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Splitting up guc.c
Date: 2022-09-13 14:05:55
Message-ID: 2038318.1663077955@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2022-09-13 14:05:56 Re: Avoid redudant initialization and possible memory leak (src/backend/parser/parse_relation.c)
Previous Message Simon Riggs 2022-09-13 14:02:34 Re: New docs chapter on Transaction Management and related changes