On Fri, Sep 9, 2011 at 11:28 PM, Peter Geoghegan <pe...@2ndquadrant.com> wrote: > It's very difficult or impossible to anticipate how effective the tool > will be in practice, but when you consider that it works and does not > produce false positives for the first 3 real-world cases tested, it > seems reasonable to assume that it's at least worth having around. Tom > recently said of a previous pgrminclude campaign in July 2006 that "It > took us two weeks to mostly recover, but we were still dealing with > some fallout in December". I think that makes the case for adding this > tool or some refinement as a complement to pgrminclude in src/tools > fairly compelling.
I'm not opposed to adding something like this, but I think it needs to either be tied into the actual running of the script, or have a lot more documentation than it does now, or both. I am possibly stupid, but I can't understand from reading the script (or, honestly, the thread) exactly what kind of pgrminclude-induced errors this is protecting against; but even if we clarify that, it seems like it would be a lot of work to run it manually on all the files that might be affected by a pgrminclude run, unless we can somehow automate that. I'm also curious to see how much more fallout we're going to see from that run. We had a few glitches when it was first done, but it didn't seem like they were really all that bad. It might be that we'd be better off running pgrminclude a lot *more* often (like once a cycle, or even after every CommitFest), because the scope of the changes would then be far smaller and we wouldn't be dealing with 5 years of accumulated cruft all at once; we'd also get a lot more experience with what works or does not work with the script, which might lead to improvements in that script on a less-than-geologic time scale. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
