Re: The pgrminclude problem

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: The pgrminclude problem
Date: 2012-08-20 15:43:44
Message-ID: CA+Tgmoa_jE78RTh8-RoYz64MYf6uHe82v=WPUm6ByGktpwTztQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 16, 2012 at 12:17 PM, Peter Geoghegan <peter(at)2ndquadrant(dot)com> wrote:
> On 16 August 2012 16:56, Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-08-20 15:58:07 Re: Primary Key Constraint on inheritance table not getting route to child tables
Previous Message Alvaro Herrera 2012-08-20 15:39:06 Re: Primary Key Constraint on inheritance table not getting route to child tables