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 →
  1. Split copy.c into four files.

  2. The contents of command.c, creatinh.c, define.c, remove.c and rename.c

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