Re: Synchronize with imath upstream

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Synchronize with imath upstream
Date: 2019-02-06 16:49:19
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2019-02-06 10:15:24 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On February 6, 2019 5:17:50 AM GMT+05:30, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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 pgindenting doesn't matter as much, as that's an automated
change. But as pgindent doesn't fix the position of declarations, that's
a significant manual process.

> 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.

Consistency surely has value, but it shouldn't block making use of new
things that become available. I don't feel extremely strongly about
allowing declarations after statements in C (while it's obviously
crucial for C++), but I do think it can be a noticably easier to reason
about the values of variables if they're declared closer to use, and
it's easier to make sure that a variable hasn't been used elsewhere that


Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2019-02-06 17:19:40 Re: pg11.1: dsa_area could not attach to segment
Previous Message Stephen Frost 2019-02-06 16:39:33 Re: Online verification of checksums