> tablecmds_partition.c, with other files named tablecmds_popo.c to
> indicate the sub-systems formerly in tablecmds.c?
As Andres mentioned, it’s good to avoid slicing too granularly, but I
also thought of the name tablecmds_partition.c as soon as I saw “split
tablecmds.c” and “partitioning code
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
> rou
> On Dec 2, 2025, at 06:43, Nathan Bossart wrote:
>
> On Mon, Dec 01, 2025 at 01:59:01PM -0500, Tom Lane wrote:
>> I didn't do any math about it, but that's got to be a far faster rate
>> of expansion than the overall PG code base. Maybe partitioning is
>> largely to blame? Perhaps analyzing
Hi,
On 2025-12-01 11:25:13 -0600, 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 t
On 2025-Dec-01, Tom Lane wrote:
> I didn't do any math about it, but that's got to be a far faster rate
> of expansion than the overall PG code base. Maybe partitioning is
> largely to blame? Perhaps analyzing what functionality got added
> here in the past dozen or so years would yield some ide
On Mon, Dec 1, 2025, at 3:18 PM, Álvaro Herrera wrote:
> 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.
>
As Tom said partitioning has a big chun
=?utf-8?Q?=C3=81lvaro?= Herrera writes:
> 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
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 tim
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,
simil
