Re: relscan_details.h - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: relscan_details.h
Date
Msg-id 20131002021205.GA7442@momjian.us
Whole thread Raw
In response to Re: relscan_details.h  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: relscan_details.h
List pgsql-hackers
On Tue, Sep 17, 2013 at 05:54:04PM -0300, Alvaro Herrera wrote:
> > 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.

Agreed, we should go ahead and make the changes.  People who use our
code for plugins are already going to have a boat-load of stuff to
change in each major release, and doing this isn't going to add a lot of
burden, and it will give us cleaner code for the future.

If we had not made massive cleanup changes years ago, our code would not
be as good as it is today.  By avoiding cleanup to reduce the burden on
people who use our code, we are positioning our code on a slow decline
in clarity.

What I don't want to do is get into a mode where every code cleanup has
to be verified that it isn't going to excessively burden outside code
users.  Cleanup is hard enough, and adding another check to that process
makes cleanup even less likely.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Daniel Farina
Date:
Subject: Re: pluggable compression support
Next
From: Peter Geoghegan
Date:
Subject: Re: relscan_details.h