Re: Splitting up guc.c
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>, Andres Freund <andres@anarazel.de>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2022-09-13T14:05:55Z
Lists: pgsql-hackers
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
Commits
-
Split up guc.c for better build speed and ease of maintenance.
- 0a20ff54f5e6 16.0 landed