Re: Proposed refactoring of planner header files - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposed refactoring of planner header files
Date
Msg-id CA+Tgmoa9kQZJ1eCDaiupQ5ZVW3c65YxnoE1NwwwdZzO=0gp=mw@mail.gmail.com
Whole thread Raw
In response to Re: Proposed refactoring of planner header files  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposed refactoring of planner header files  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jan 30, 2019 at 10:08 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> However ... there are three pretty clearly identifiable groups of
> functions in selfuncs.c: operator-specific estimators, support
> functions, and AM-specific indexscan cost estimation functions.
> There's a case to be made for splitting them into three separate files.
> One point is that selfuncs.c is just too large; at over 8K lines,
> it's currently the 7th-largest hand-maintained C file in our tree.
> Another point is that as things stand, there's a strong temptation
> to bury useful functionality in static functions that can't be
> gotten at by extension estimators.  Separating the support functions
> might help keep us more honest on that point.  (Or not.)
>
> I'm not sure whether those arguments are strong enough to justify
> the added pain-in-the-neck factor from moving a bunch of code
> around.  That complicates back-patching bug fixes and it makes it
> harder to trace the git history of the code.  So I've got mixed
> emotions about whether it's worth doing anything.

I think splitting it along these lines would be pretty sensible.  I'm
not really a fan of giant source files, especially if there's no
really good reason to put all that stuff in one source file ... then
again, I'm also not volunteering to do the work.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: possible deadlock: different lock ordering for heap pages
Next
From: Carter Thaxton
Date:
Subject: Re: Add --include-table-data-where option to pg_dump, to export onlya subset of table data