Re: Large C files - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Large C files
Date
Msg-id CA+U5nM+BE6JLDd39a6aGa87SpkGtJ+QzPFNRy-PTYV6MWG5Djw@mail.gmail.com
Whole thread Raw
In response to Re: Large C files  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Large C files
Re: Large C files
Re: Large C files
List pgsql-hackers
On Thu, Sep 8, 2011 at 3:25 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
>> On Wed, Sep 7, 2011 at 9:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Simon Riggs <simon@2ndQuadrant.com> writes:
>>>> Please lets not waste effort on refactoring efforts in mid dev cycle.
>
>>> Say what?  When else would you have us do it?
>
>> When else would you have us develop?
>
> In my eyes that sort of activity *is* development.  I find the
> distinction you are drawing entirely artificial, and more calculated to
> make sure refactoring never happens than to add any safety.  Any
> significant development change carries a risk of breakage.

You clearly have the bit between your teeth on this.

That doesn't make it worthwhile or sensible though.

I've offered to do it slowly and carefully over time, but that seems
not enough for some reason. What is the real reason for this?

I assume whoever does it will be spending significant time on testing
and bug fixing afterwards. I foresee lots of "while I'm there, I
thought I'd just mend X", so we'll spend lots of time fighting to keep
functionality that's already there. Look at the discussion around
archive_command for an example of that.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Fast GiST index build - further improvements
Next
From: Bruce Momjian
Date:
Subject: Re: Large C files