Horton

Re: split tablecmds.c

Álvaro Herrera <alvherre@kurilemu.de>

View thread
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2025-12-01T18:18:13Z
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 2025-Dec-01, Nathan Bossart wrote:

> This file has over 22,000 lines and is too large to be included in GitHub's
> code search results [0].  It appears to have been given its current form in
> 2002 by commit 71dc300.  Previously, it was named command.c, which dates
> back to the 80s.  Is it time to split it into a few different files,
> similar to what was done to copy.c in 2020 by commit c532d15?
> 
> After briefly skimming through it, some areas that seem like they could
> potentially be moved out are partitions, constraints, permission checks,
> inheritance, foreign keys, column expressions, table rewriting, attribute
> merging, TRUNCATE, and CREATE TABLE.  This is far from a concrete proposal,
> but I first wanted to gauge interest in $SUBJECT.

I think it makes sense.  It's our largest source file at 690kB
the second being pg_dump.c (at 625kB) and also a candidate for
splitting.  The third one, ruleutils.c, is slightly above half size,
381kB!

My first thought would be to move code that deals with catalog changes
to files in catalog/.  Also a couple of functions related to tablespaces
could be perhaps be moved to commands/tablespace.c.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte"
(Ijon Tichy en Viajes, Stanislaw Lem)