Re: Refactoring pgbench.c

On 06/28/15 18:56, Tatsuo Ishii wrote:
>>> I do not think that this large file is a so big a problem (good
>>> editors help navigation in the code), and I'm not sure that splitting
>>> it would achieve much: there are not that many functions, some of
>>> them are maybe long (main, threadRun, doCustom) but mostly for good
>>> reasons.
>>
>> My thoughts, exactly. I don't think just splitting the file into
>> multiple pieces will achieve anything - the problem is that we've
>> extended the original pgbench code in rather hackish way, without any
>> major design changes, so IMHO what should be done is refactoring ...
>
> This is kind of surprising to me that two people are against
> refactoring proposal (I understand that Fabien has pending patches
> for pgbench and that could be a motivation for this though).

I think that's a misunderstanding. I'm not against refactoring - not at
all, and neither is Fabien I believe. However the first paragraph of
your post seems to suggest that we get better code by merely splitting
the a large file into several smaller ones.

I don't think that alone helps - I think we first need to refactor the
code first, and then possibly split the file into several modules.

> Splitting single large file into smaller files in which functions
> contain strong relation will be itself a benefit since there will be
> more chance for people to be needed to look into smaller places than
> before. This is just a basic idea of modular programming and will be
> a long term benefit of PostgreSQL project, which was my thought.

I respectfully disagree. I think that for this to be true, the files
need to be somehow logically related (which I'd expect to be the output
of the refactoring). But maybe you have some particular refactoring and
split in mind?

best regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services