On Wed, Feb 06, 2019 at 10:15:24AM -0500, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On February 6, 2019 5:17:50 AM GMT+05:30, Alvaro Herrera > > <alvhe...@2ndquadrant.com> wrote: > >> I'm -1 for this myself. I think there are a few places that could > >> benefit from it, but my fear is that many *more* places would get > >> worse. > > > Because of imported code like ryu and imath? And because it can make code > > considerably better when used judiciously. > > I don't object to keeping imported code in a form that matches upstream > as best we can. (Should we also exclude such files from pgindent'ing?)
I think it depends on how much time one spends merging upstream changes versus making PostgreSQL-specific edits. For IMath, both amounts are too small to get excited about. Does pgindent materially complicate src/timezone merges? > But changing conventions for our own code is an entirely different matter. > In this case, I think that having some places use it while the bulk of > the code doesn't is just a bad idea from a stylistic-consistency > standpoint. It's pretty much the same reason why we still aren't allowing > // comments --- there's no toolchain-based reason not to, but a mishmash of > comment styles would be ugly and hard to read. (This debate never belonged in this thread, but it's too late now.) I find code easiest to follow when the declaration appears as late as possible. I would welcome mixed declarations and code, and I would not mourn the loss of consistency. In terms of consistency damage, this is similar to adding psprintf() without exterminating palloc()+snprintf(). I'm glad we introduce ways to write new, cleaner code despite the inconsistency with older code.
