Chris Browne <[EMAIL PROTECTED]> writes: > Would it be a terrible idea to... > > - Draw the indent code from NetBSD into src/tools/pgindent
I am not real eager to become maintainers of our own indent fork, which is what you propose. (Just for starters, what will we have to do to make it run on non-BSD systems?) > We are presently at the extreme position where pgindent is run once in > a very long time (~ once a year), at pretty considerable cost, and > with the associated cost that a whole lot of indentation problems are > managed by hand. Yeah. One reason for that is that the typedef problem makes it a pretty manual process. The main problem I see with "pgindent early and often" is that it only works well if everyone is using exactly the same pgindent code (and exactly the same typedef list). Otherwise you just get buried in useless whitespace diffs. It's bad enough that Bruce whacks around his copy from time to time :-(. I would say that the single greatest annoyance for maintaining our back branches is that patches tend to not back-patch cleanly, and well over half the time it's because of random reformattings done by pgindent to code that hadn't changed at all, but it had formatted differently the prior year. For the same reason, my take on your "random whitespace changes are acceptable" theory is not no but hell no. It's gonna cost us, permanently, in manual patch adjustments if we allow the repository to get cluttered with content-free diffs. I guess an advantage of maintaining our own fork is that there'd be Only One True pgindent, thereby alleviating that problem; but I'm still not eager to go there. If we were going to do it, I'd really wish that we could standardize on a version that didn't need a typedef list. The random whitespace changes you get after changing the typedef list are another thorn in my side. But in any case, this is all focusing on trivialities. The stuff pgindent can fix is, by definition, stuff that committers don't really have to worry about during patch review. The stuff I'm worried about is at a higher level than that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers