Re: relscan_details.h

Robert Haas escribió:

> Personally, I'm not particularly in favor of these kinds of changes.
> The changes we made last time broke a lot of extensions - including
> some proprietary EDB ones that I had to go fix.  I think a lot of
> people spent a lot of time fixing broken builds, at EDB and elsewhere,
> as well as rebasing patches.  And the only benefit we have to balance
> that out is that incremental recompiles are faster, and I'm not really
> sure how important that actually is.  On my system, configure takes 25
> seconds and make -j3 takes 65 seconds; so, even a full recompile is
> pretty darn fast, and an incremental recompile is usually really fast.
>  Now granted this is a relatively new system, but still.

Fortunately the machines I work on now are also reasonably fast.  There
was a time when my desktop was so slow that it paid off to tweak certain
file timestamps to avoid spurious recompiles.  Now I don't have to
worry.  But it still annoys me that I have enough time to context-switch
to, say, the email client or web browser, from where I don't switch back
so quickly; which means I waste five or ten minutes for a task that
should have taken 20 seconds.

Now, htup_details.h was a bit different than the case at hand because
there's evidently lots of code that want to deal with the guts of
tuples, but for scans you mainly want to start one, iterate and finish,
but don't care much about the innards.  So the cleanup work required is
going to be orders of magnitude smaller.

OTOH, back then we had the alternative of doing the split in such a way
that third-party code wouldn't have been affected that heavily, but we
failed to take that into consideration.  I trust we have all learned
that lesson and will keep it in mind for next time.

> I don't want to be too dogmatic in opposing this; I accept that we
> should, from time to time, refactor things.  If we don't, superflouous
> dependencies will probably proliferate over time.  But personally, I'd
> rather do these changes in bulk every third release or so and keep
> them to a minimum in between times, so that we're not forcing people
> to constantly decorate their extensions with new #if directives.

We can batch things, sure, but I don't think doing it only once every
three years is the right tradeoff.  There's not all that much of this
refactoring, after all.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services