Re: The pgrminclude problem - Mailing list pgsql-hackers

From Robert Haas
Subject Re: The pgrminclude problem
Date
Msg-id CA+Tgmoa_jE78RTh8-RoYz64MYf6uHe82v=WPUm6ByGktpwTztQ@mail.gmail.com
Whole thread Raw
In response to Re: The pgrminclude problem  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: The pgrminclude problem
Re: The pgrminclude problem
List pgsql-hackers
On Thu, Aug 16, 2012 at 12:17 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 16 August 2012 16:56, Bruce Momjian <bruce@momjian.us> wrote:
>> Good to know. We only use pgrminclude very five years or so, and Tom
>> isn't even keen on that.
>
> Yeah. Even if this could be made to work well, we'd still have to do
> something like get an absolute consensus from all build farm animals,
> if we expected to have an absolutely trustworthy list. I don't think
> pgrminclude is a bad idea. I just think that it should only be used to
> guide the efforts of a human to remove superfluous #includes, which is
> how it is used anyway.

I actually think we'd probably be better off running pgrminclude once
per release cycle rather than any less often.  When the number of
changes gets into the hundreds or thousands of lines it becomes much
more difficult to validate that it's doing anything sensible.  I ran
it a while back and found a bunch of stuff that looked like it was
obviously worth fixing, but I was afraid of getting yelled at if I
went and fixed it, so I didn't.  Somehow that doesn't seem like an
ideal situation...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Primary Key Constraint on inheritance table not getting route to child tables
Next
From: Tom Lane
Date:
Subject: Re: Primary Key Constraint on inheritance table not getting route to child tables