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