On Tue, Jun 9, 2015 at 09:56:13PM -0400, Robert Haas wrote:
> What I really don't want to do is apply the pgindent diff somewhat
> blindly, without really knowing how many cases we're improving and how
> many cases we're making worse. The number of times we've run pgindent
> and then realized lat
On Tue, May 26, 2015 at 2:55 PM, Robert Haas wrote:
> This is kind of why I think that reindenting the back branches is
> unlikely to be productive: it only helps if you can get pgindent to do
> the same thing on all branches, and I bet that's going to be tough.
...but having said that and though
On 5/27/15 5:08 PM, Andres Freund wrote:
> I don't think I need to. clang-format has apparently done pretty much
> what I described:
Well, that appears to work reasonably well in practice, which is all we
can hope for. Unfortunately, clang-format makes a bit of a mess of some
of our code, so it i
On 05/27/2015 05:19 PM, Peter Eisentraut wrote:
And even if we got to the point where all commits should be perfectly
pgindented, it wouldn't work, because under the current workflow the
updated typedef list isn't available until after the commit (on an
unpredictable schedule). (This problem w
On 5/27/15 2:55 PM, Tom Lane wrote:
> These are all things we might try to fix (where "fix" could include
> "replace it with another tool") if the back-patching pain created by even
> minor changes of the formatting rules weren't so great. But at this point
> I despair of getting to consensus on a
On 2015-05-27 16:55:45 -0400, Peter Eisentraut wrote:
> On 5/26/15 8:31 PM, Andres Freund wrote:
> > I actually think both are relatively easy to figure out without a
> > typedef list. There's harder cases though, e.g. (char *) &foo in an
> > expression is already more complicated.
>
> Well, if yo
On 5/26/15 8:31 PM, Andres Freund wrote:
> I actually think both are relatively easy to figure out without a
> typedef list. There's harder cases though, e.g. (char *) &foo in an
> expression is already more complicated.
Well, if you know of a way to fix this, let's see it. Others have been
tryin
Andres Freund writes:
> But really, the typedef list is the minor part what annoys me about
> pgindent. That it completely butchers so many constructs (e.g. function
> pointer typedefs, inline asm as extreme examples) is much worse.
These are all things we might try to fix (where "fix" could incl
On 05/27/2015 11:53 AM, Bruce Momjian wrote:
On Wed, May 27, 2015 at 02:31:07AM +0200, Andres Freund wrote:
But really, the typedef list is the minor part what annoys me about
pgindent. That it completely butchers so many constructs (e.g. function
pointer typedefs, inline asm as extreme example
On Wed, May 27, 2015 at 02:31:07AM +0200, Andres Freund wrote:
> But really, the typedef list is the minor part what annoys me about
> pgindent. That it completely butchers so many constructs (e.g. function
> pointer typedefs, inline asm as extreme examples) is much worse. It's
> also neigh on impo
On Tue, May 26, 2015 at 04:32:42PM -0300, Alvaro Herrera wrote:
> Robert Haas wrote:
>
> > But every time we pgindent, especially with slightly different
> > settings, we cause tools like 'git blame' to return less useful
> > answers. And that sucks.
>
> I've wondered a few times whether there's
On Tue, May 26, 2015 at 3:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> Realistically, with merge.conflictstyle = diff3 (why is this not the
>> default?), resolving whitespace conflicts that occur when you try to
>> cherry-pick is typically not very difficult.
>
> Really? The problems I have g
On 5/25/15 5:51 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>
>> A longer-term fix would be to make pgindent less stupid about this sort
>> of usage, but nobody's yet volunteered to dig into the guts of that code.
>
> We've discussed in the past that we could use something other than BSD's
> inde
On 2015-05-26 20:25:24 -0400, Peter Eisentraut wrote:
> On 5/25/15 7:15 PM, Andres Freund wrote:
> > On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote:
> >>> A longer-term fix would be to make pgindent less stupid about this sort
> >>> of usage, but nobody's yet volunteered to dig into the guts of
On 5/25/15 7:15 PM, Andres Freund wrote:
> On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote:
>>> A longer-term fix would be to make pgindent less stupid about this sort
>>> of usage, but nobody's yet volunteered to dig into the guts of that code.
>>
>> I assume a typedefs list is going to be a req
On 2015-05-26 16:32:42 -0300, Alvaro Herrera wrote:
> I've wondered a few times whether there's a way to make pgindent commits
> "transparent" to git blame, i.e. blame their modified lines to whatever
> commits modified them immediately before.
You can make blame ignore whitespace changes with -w
On Tue, May 26, 2015 at 3:07 PM, Tom Lane wrote:
> Robert Haas writes:
> > Realistically, with merge.conflictstyle = diff3 (why is this not the
> > default?), resolving whitespace conflicts that occur when you try to
> > cherry-pick is typically not very difficult.
>
> Really? The problems I ha
On 05/25/2015 05:34 PM, Tom Lane wrote:
Bruce Momjian writes:
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
Something is wrong. See aclchk.c changes.
Yes, this is what I was concerned about. "aclitem" was a typedef in 9.0
and 9.1, and the use of that as a typedef in 9.4 i
Robert Haas wrote:
> But every time we pgindent, especially with slightly different
> settings, we cause tools like 'git blame' to return less useful
> answers. And that sucks.
I've wondered a few times whether there's a way to make pgindent commits
"transparent" to git blame, i.e. blame their m
Robert Haas writes:
> Realistically, with merge.conflictstyle = diff3 (why is this not the
> default?), resolving whitespace conflicts that occur when you try to
> cherry-pick is typically not very difficult.
Really? The problems I have generally come from places where pgindent
has changed the l
On Mon, May 25, 2015 at 5:34 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
>>> Something is wrong. See aclchk.c changes.
>
>> Yes, this is what I was concerned about. "aclitem" was a typedef in 9.0
>> and 9.1, and the use of that
Bruce Momjian writes:
> On Tue, May 26, 2015 at 01:15:17AM +0200, Andres Freund wrote:
>> Maybe I'm missing something major here, but why? Afaict it's just only
>> used for formatting decisions that could be made without it just as well?
> Uh, well, formatting decisions is what pgindent does. It
On Tue, May 26, 2015 at 01:15:17AM +0200, Andres Freund wrote:
> On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote:
> > > A longer-term fix would be to make pgindent less stupid about this sort
> > > of usage, but nobody's yet volunteered to dig into the guts of that code.
> >
> > I assume a typed
On 2015-05-25 19:01:28 -0400, Bruce Momjian wrote:
> > A longer-term fix would be to make pgindent less stupid about this sort
> > of usage, but nobody's yet volunteered to dig into the guts of that code.
>
> I assume a typedefs list is going to be a requirement of any decent C
> indenting tool.
On Mon, May 25, 2015 at 05:34:12PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
> >> Something is wrong. See aclchk.c changes.
>
> > Yes, this is what I was concerned about. "aclitem" was a typedef in 9.0
> > and 9.1, and the
On Mon, May 25, 2015 at 06:48:47PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > >
> > > > OK, makes sense. You can see the old and 'all' diffs here:
> > > >
> > > > http://momjian.us
Alvaro Herrera writes:
> Tom Lane wrote:
>> A longer-term fix would be to make pgindent less stupid about this sort
>> of usage, but nobody's yet volunteered to dig into the guts of that code.
> We've discussed in the past that we could use something other than BSD's
> indent -- astyle has been m
Tom Lane wrote:
> A longer-term fix would be to make pgindent less stupid about this sort
> of usage, but nobody's yet volunteered to dig into the guts of that code.
We've discussed in the past that we could use something other than BSD's
indent -- astyle has been mentioned. It seems that with s
Bruce Momjian wrote:
> On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > OK, makes sense. You can see the old and 'all' diffs here:
> > >
> > > http://momjian.us/expire/
> >
> > Something is wrong. See aclchk.c changes.
>
> Yes, this is what
Bruce Momjian writes:
> On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
>> Something is wrong. See aclchk.c changes.
> Yes, this is what I was concerned about. "aclitem" was a typedef in 9.0
> and 9.1, and the use of that as a typedef in 9.4 is certainly odd:
> - ac
On Mon, May 25, 2015 at 04:52:38PM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > OK, makes sense. You can see the old and 'all' diffs here:
> >
> > http://momjian.us/expire/
>
> Something is wrong. See aclchk.c changes.
Yes, this is what I was concerned about. "aclitem" was a
Bruce Momjian wrote:
> One issue I discussed is doing a pgindent-only release so users doing a
> diff would not have pgindent diffs mixed with fixes.
I doubt anyone is reading hand-generated diffs these days. Those that
want to read diffs are much better served by looking at the git repo
directl
Bruce Momjian writes:
> On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote:
>> As we discussed upthread, if we're trying to minimize cross-branch
>> pgindent differences then we probably need to use the same typedefs
>> list in all branches. I believe Andrew's already set up buildfarm
>> su
Bruce Momjian writes:
> On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote:
>> Some of those diffs would disappear if you'd used an up-to-date typedefs
>> list ... not a lot, but some.
> Uh, you mean a current 9.4.X typedef list? Should I try that?
As we discussed upthread, if we're tryin
On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Here is a re-run of pgindent on 9.4:
> > http://momjian.us/expire/pgindent-9.4.diff
>
> Some of those diffs would disappear if you'd used an up-to-date typedefs
> list ... not a lot, but some.
Uh, you mean
Tom Lane wrote:
> Alvaro Herrera writes:
> > FWIW the multixact code is now slightly different between HEAD and
> > 9.3/9.4, also. So if that needs further patches, they will be fun to
> > backpatch.
>
> Well, sure, intentional cross-branch changes are always a hazard.
> But pgindent diffs are a
Bruce Momjian wrote:
> OK, makes sense. You can see the old and 'all' diffs here:
>
> http://momjian.us/expire/
Something is wrong. See aclchk.c changes.
Also, sometime ago we changed pgindent rules so that dot-space-space is
not turned into dot-tab in comments anymore, and many places
On 2015-05-25 14:55:54 -0400, Bruce Momjian wrote:
> One issue I discussed is doing a pgindent-only release so users doing a
> diff would not have pgindent diffs mixed with fixes.
I find a pgindent only release a pretty pointless goal. That's what git
is for.
--
Sent via pgsql-hackers mailing l
Alvaro Herrera writes:
> FWIW the multixact code is now slightly different between HEAD and
> 9.3/9.4, also. So if that needs further patches, they will be fun to
> backpatch.
Well, sure, intentional cross-branch changes are always a hazard.
But pgindent diffs are a hazard that we could mechanic
On Mon, May 25, 2015 at 12:49:41PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > If we wanted to do this on backbranches, I think we would create a diff
> > file of the minor release just before running pgindent and stamping so
> > users could see the non-pgindent content of the release.
>
>
On Mon, May 25, 2015 at 01:28:16PM -0400, Tom Lane wrote:
> What we need to consider right now is whether to include back branches
> in the existing practice of reindenting between development cycles.
> This is somewhat urgent because we already did HEAD, so we have already
> created a divergence f
On Mon, May 25, 2015 at 09:00:25PM +0200, Andres Freund wrote:
> On 2015-05-25 14:55:54 -0400, Bruce Momjian wrote:
> > One issue I discussed is doing a pgindent-only release so users doing a
> > diff would not have pgindent diffs mixed with fixes.
>
> I find a pgindent only release a pretty point
Bruce Momjian writes:
> On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote:
>> The point is for the back branches to absorb pgindent-induced changes that
>> have already happened in HEAD, so I'm not sure what you're getting at.
> My point is uses of new typedefs names added in HEAD which ar
On Mon, May 25, 2015 at 03:20:47PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote:
> >> The point is for the back branches to absorb pgindent-induced changes that
> >> have already happened in HEAD, so I'm not sure what you're getting at
On Mon, May 25, 2015 at 03:12:24PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote:
> >> As we discussed upthread, if we're trying to minimize cross-branch
> >> pgindent differences then we probably need to use the same typedefs
> >> list
On Mon, May 25, 2015 at 03:03:00PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 25, 2015 at 01:10:04PM -0400, Tom Lane wrote:
> >> Some of those diffs would disappear if you'd used an up-to-date typedefs
> >> list ... not a lot, but some.
>
> > Uh, you mean a current 9.4.X typed
Tom Lane wrote:
> What we need to consider right now is whether to include back branches
> in the existing practice of reindenting between development cycles.
> This is somewhat urgent because we already did HEAD, so we have already
> created a divergence from HEAD to 9.4 which is going to cause u
Andres Freund writes:
> On 2015-05-20 11:47:15 -0400, Robert Haas wrote:
>> On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote:
>>> To do it before every minor release would require re-indenting HEAD
>>> as well (since the whole point is to keep HEAD and the back branches
>>> consistent). I think
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-05-20 11:47:15 -0400, Robert Haas wrote:
> > On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote:
> > > To do it before every minor release would require re-indenting HEAD
> > > as well (since the whole point is to keep HEAD and the back branches
On 2015-05-20 11:47:15 -0400, Robert Haas wrote:
> On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote:
> > To do it before every minor release would require re-indenting HEAD
> > as well (since the whole point is to keep HEAD and the back branches
> > consistent). I think we'd get too much push-bac
Bruce Momjian writes:
> Here is a re-run of pgindent on 9.4:
> http://momjian.us/expire/pgindent-9.4.diff
Some of those diffs would disappear if you'd used an up-to-date typedefs
list ... not a lot, but some.
That is rather a lot of diffs, but the thing I think people ought to take
away fr
Bruce Momjian writes:
> If we wanted to do this on backbranches, I think we would create a diff
> file of the minor release just before running pgindent and stamping so
> users could see the non-pgindent content of the release.
What for? Those who want to see that can look at our git repo.
> A
On Sat, May 23, 2015 at 12:32:34PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Are we ready for a pgindent run? Back branches?
>
> I think we could do it in HEAD, but it doesn't seem like we have consensus
> about whether to touch the back branches. Suggest just HEAD for now and
> we can
On Sun, May 24, 2015 at 10:44:10AM -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 05/23/2015 11:37 PM, Tom Lane wrote:
> >> No, pgindent has *always* been wonky about lines that contain a typedef
> >> name but are not variable declarations.
>
> > Well, that sounds like something we should
On Sun, May 24, 2015 at 08:31:32AM -0400, Bruce Momjian wrote:
> > >> Also, does somebody have an idea to keep pgindent from butchering inline
> > >> asm like:
> >
> > > Ah, we have a file /pgtop/src/tools/pgindent/exclude_file_patterns which
> > > has excluded files, and s_lock.h is one of them.
Andrew Dunstan writes:
> On 05/23/2015 11:37 PM, Tom Lane wrote:
>> No, pgindent has *always* been wonky about lines that contain a typedef
>> name but are not variable declarations.
> Well, that sounds like something we should try to patch, doesn't it?
> (No, I'm not volunteering.)
In the past
On 05/23/2015 11:37 PM, Tom Lane wrote:
Bruce Momjian writes:
On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
- if (IsA(node, Aggref) || IsA(node, GroupingFunc))
+ if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
There's a bunch of changes like this. Looks rather odd to me
On Sat, May 23, 2015 at 11:37:30PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
> >> - if (IsA(node, Aggref) || IsA(node, GroupingFunc))
> >> + if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
> >>
> >> There's a bunch of ch
Bruce Momjian writes:
> On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
>> - if (IsA(node, Aggref) || IsA(node, GroupingFunc))
>> + if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
>>
>> There's a bunch of changes like this. Looks rather odd to me? I don't
>> recall seing much
On Sun, May 24, 2015 at 04:16:07AM +0200, Andres Freund wrote:
> On 2015-05-23 21:36:50 -0400, Bruce Momjian wrote:
> > pgindent run on HEAD and committed.
>
> - if (IsA(node, Aggref) || IsA(node, GroupingFunc))
> + if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
>
> There's a bunch of chang
On 2015-05-23 21:36:50 -0400, Bruce Momjian wrote:
> pgindent run on HEAD and committed.
- if (IsA(node, Aggref) || IsA(node, GroupingFunc))
+ if (IsA(node, Aggref) ||IsA(node, GroupingFunc))
There's a bunch of changes like this. Looks rather odd to me? I don't
recall seing much code looking
On Sat, May 23, 2015 at 12:32:34PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Are we ready for a pgindent run? Back branches?
>
> I think we could do it in HEAD, but it doesn't seem like we have consensus
> about whether to touch the back branches. Suggest just HEAD for now and
> we can
Bruce Momjian writes:
> Are we ready for a pgindent run? Back branches?
I think we could do it in HEAD, but it doesn't seem like we have consensus
about whether to touch the back branches. Suggest just HEAD for now and
we can continue to argue about the back branches.
r
On Fri, May 22, 2015 at 12:02:11PM -0400, Tom Lane wrote:
> I guess in the
> scenario you're describing, the most helpful thing would be if the
> pgindent commit put the typedef list it had used into the tree, and then
> we just use that (plus manual additions) when generating the I' commit.
I hav
Alvaro Herrera writes:
> Tom Lane wrote:
>> Alvaro Herrera writes:
>>> I believe it's possible to mechanically rebase a patch over an indent
>>> run of the underlying branch with half a dozen commands or less. +1 for
>>> reindenting all branches before each minor release, FWIW.
>> Yeah? Can yo
Tom Lane wrote:
> Alvaro Herrera writes:
> > I believe it's possible to mechanically rebase a patch over an indent
> > run of the underlying branch with half a dozen commands or less. +1 for
> > reindenting all branches before each minor release, FWIW.
>
> Yeah? Can you show an example?
So we
Alvaro Herrera writes:
> Robert Haas wrote:
>> On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote:
>>> To do it before every minor release would require re-indenting HEAD
>>> as well (since the whole point is to keep HEAD and the back branches
>>> consistent). I think we'd get too much push-back f
Robert Haas wrote:
> On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote:
> > To do it before every minor release would require re-indenting HEAD
> > as well (since the whole point is to keep HEAD and the back branches
> > consistent). I think we'd get too much push-back from developers
> > whose pe
On Tue, May 19, 2015 at 10:26 AM, Tom Lane wrote:
> To do it before every minor release would require re-indenting HEAD
> as well (since the whole point is to keep HEAD and the back branches
> consistent). I think we'd get too much push-back from developers
> whose pending patches got broken. We
Robert Haas writes:
> On Mon, May 18, 2015 at 6:53 PM, Tom Lane wrote:
>> Would it alleviate your concern any if we eased into this, like say only
>> apply the back-branch pgindent run to 9.5 and later branches? Then at
>> least I could foresee the end of that particular annoyance.
> If we do t
Andrew Dunstan writes:
> Tom, if you want to get dromedary reporting on all branches, just
> remove the "branches => [ 'HEAD' ]," from the config.
dromedary is a pretty slow machine, so I'm going to pass on that unless
there's a good reason to think it would find typedefs your machines don't.
I
On Mon, May 18, 2015 at 6:53 PM, Tom Lane wrote:
>> I am personally not excited about that. I would rather leave the
>> back-branches alone.
>
> It would be awfully nice though if we didn't have to deal with random
> cross-branch indenting differences. I've lost, maybe not years off my
> life, b
On 05/18/2015 08:06 PM, Andrew Dunstan wrote:
On 05/18/2015 07:04 PM, Bruce Momjian wrote:
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
Robert Haas writes:
On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian
wrote:
There was talk last time of pgindent-ing head and all back branch
On 05/18/2015 07:04 PM, Bruce Momjian wrote:
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
Robert Haas writes:
On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian wrote:
There was talk last time of pgindent-ing head and all back branches,
because a patch applied to head and back bra
On Mon, May 18, 2015 at 07:10:00PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
> >> (BTW, one practical issue is where would we get typedef lists relevant
> >> to the back branches. I'm not sure if the buildfarm infrastructure is
>
Bruce Momjian writes:
> On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
>> (BTW, one practical issue is where would we get typedef lists relevant
>> to the back branches. I'm not sure if the buildfarm infrastructure is
>> capable of collecting branch-specific data, or if we'd need to ra
On Mon, May 18, 2015 at 06:53:00PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian wrote:
> >> There was talk last time of pgindent-ing head and all back branches,
> >> because a patch applied to head and back branches was historically only
> >> pg
Robert Haas writes:
> On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian wrote:
>> There was talk last time of pgindent-ing head and all back branches,
>> because a patch applied to head and back branches was historically only
>> pgindented in head, meaning that any future patches in that area could
On Mon, May 18, 2015 at 12:10 PM, Bruce Momjian wrote:
> On Sat, May 16, 2015 at 01:05:27PM -0400, Tom Lane wrote:
>> Magnus Hagander writes:
>> > On Sat, May 16, 2015 at 5:58 PM, Tom Lane wrote:
>> >> With feature freeze behind us, I'd like to propose that now is a good
>> >> time for a pginden
On Sat, May 16, 2015 at 01:05:27PM -0400, Tom Lane wrote:
> Magnus Hagander writes:
> > On Sat, May 16, 2015 at 5:58 PM, Tom Lane wrote:
> >> With feature freeze behind us, I'd like to propose that now is a good
> >> time for a pgindent run.
>
> > +1, except I suggest we at least delay it until
Magnus Hagander writes:
> On Sat, May 16, 2015 at 5:58 PM, Tom Lane wrote:
>> With feature freeze behind us, I'd like to propose that now is a good
>> time for a pgindent run.
> +1, except I suggest we at least delay it until we have wrapped the new
> minor releases, to make sure we don't confli
On Sat, May 16, 2015 at 11:58:59AM -0400, Tom Lane wrote:
> With feature freeze behind us, I'd like to propose that now is a good
> time for a pgindent run. It's possible we'd need another one before
> 9.5 is branched off from HEAD, but a run now ought to take care of 95%
> of the cleanup needed.
On Sat, May 16, 2015 at 5:58 PM, Tom Lane wrote:
> With feature freeze behind us, I'd like to propose that now is a good
> time for a pgindent run. It's possible we'd need another one before
> 9.5 is branched off from HEAD, but a run now ought to take care of 95%
> of the cleanup needed. I see
With feature freeze behind us, I'd like to propose that now is a good
time for a pgindent run. It's possible we'd need another one before
9.5 is branched off from HEAD, but a run now ought to take care of 95%
of the cleanup needed. I see a couple of advantages to doing it now:
1. Patches that ar
84 matches
Mail list logo
