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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
