From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgindent run next week? |
Date: | 2019-05-22 19:27:18 |
Message-ID: | 10207.1558553238@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> In my experience, changes to function declarations in header files
> happen a lot in forks. So applying the pgindent change to backbranches
> would cause some trouble.
> On the other hand, it seems to me that patches that we backpatch between
> PostgreSQL branches should normally not touch function declarations in
> header files, since that would be an ABI break. So by not applying the
> pgindent change in backbranches we don't lose anything. And so it would
> be better to just leave things as they are.
Maybe we could wait awhile and see how much pain we find in back-patching
across this change. I have to admit that the v10 pgindent changes have
not been as painful as I expected them to be, so maybe this round will
also prove to be just an annoyance not a major PITA for that.
Another thought is that, at least in principle, we could re-indent only
.c files not .h files in the back branches. But I'm not sure I believe
your argument that forks are more likely to touch exposed extern
declarations than local static declarations.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-05-22 19:44:38 | Re: PostgreSQL 12 Beta 1 press release draft |
Previous Message | Tom Lane | 2019-05-22 19:21:53 | Re: "long" type is not appropriate for counting tuples |