Re: Proposed refactoring of planner header files

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Proposed refactoring of planner header files
Дата
Msg-id CA+Tgmoa9kQZJ1eCDaiupQ5ZVW3c65YxnoE1NwwwdZzO=0gp=mw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposed refactoring of planner header files  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proposed refactoring of planner header files  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: possible deadlock: different lock ordering for heap pages
Следующее
От: Carter Thaxton
Дата:
Сообщение: Re: Add --include-table-data-where option to pg_dump, to export onlya subset of table data