Re: split tablecmds.c
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Álvaro Herrera <alvherre@kurilemu.de>, pgsql-hackers@postgresql.org, euler@eulerto.com, andres@anarazel.de
Date: 2025-12-02T00:03:53Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Split copy.c into four files.
- c532d15dddff 14.0 cited
-
The contents of command.c, creatinh.c, define.c, remove.c and rename.c
- 71dc300a375f 7.3.1 cited
On Mon, Dec 01, 2025 at 04:43:37PM -0600, Nathan Bossart wrote: > I tried to move the partitioning-related code to a new file, and it wasn't > too bad. Note that there are a couple of internal-to-tablecmds.c things > that need to be exported. Besides that, the attached patch is still pretty > rough, and I'm not sure I correctly placed the line in the sand when > determining what stays and what goes, but this at least shows the general > shape of what's needed. (BTW git was generating an atrocious diff for > tablecmds.c. You might need to set the diff algorithm to "minimal" if you > are similarly affected.) Moving all the partition-specific code into a different file makes sense here. Is partcmds.c as name the best fit though? Perhaps a tablecmds_partition.c, with other files named tablecmds_popo.c to indicate the sub-systems formerly in tablecmds.c? > src/backend/commands/Makefile | 1 + > src/backend/commands/meson.build | 1 + > src/backend/commands/partcmds.c | 3377 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > src/backend/commands/tablecmds.c | 3456 +-------------------------------------------------------------------------------------------- > src/backend/partitioning/partbounds.c | 1 + > src/include/commands/partcmds.h | 53 ++ > src/include/commands/tablecmds.h | 134 +++- > 7 files changed, 3575 insertions(+), 3448 deletions(-) The new contents of tablecmds.h don't have any strong dependency with tablecmds.h, so perhaps having the "internal" structures like the ones you are moving here into a new tablecmds_internal.h would be cleaner? Another sub-area of tablecmds.c that could be split is I think the rewrite logic. It has a lot of its own perks that become harder to figure out the more tablecmds.c gets bloated. -- Michael