Re: Triaging the remaining open commitfest items

On 2015-05-15 18:00:49 +0200, Andres Freund wrote:
> On 2015-05-14 23:28:33 +0200, Andres Freund wrote:
> > I've removed the use of GroupedVars and Andrew is right now working on
> > structural changes. I'm not ready at this point to make a judgement.
>
> Andrew worked really hard and addressed the voiced concerns with the way
> chaining was done. In my last read through I found a bunch of stylistic
> quibbles and a question about behaviour where reading the spec confirmed
> that the current implementation is actually correct ( grouping sets +
> functional dependencies => weird).
>
> I plan to post a squashed patches from what's in git now in a couple
> hours and then, unless something major (issues, protest) comes up, push
> PDT late afternoon.

Here's why I think it's somewhat important that we make progress on the
issue, and why I want to go ahead with this:

In my eye Tom has, I'll assume unintentionally, stalled progress on this
patch for nearly half a year. Due to Tom's profile it's unlikely that
somebody else is going to seriously tackle a nontrivial patch that Tom
has laid claims to. Especially if fundamental objections have been
made, without also painting a way forward. In addition, by commenting
on various triage emails that he'll get to it at some point, Tom in my
view essentially has cemented that claim.

Due to that I think the issue can't be characterized, as done nearby, as
one of unduly laying claims to Tom's time, which obviously is his own to
manage. The way it turned out people were forced to do that.

I do think that part of the problem is that Andrew (Gierth, not Dunstan)
isn't always easy to work with. Particularly there seems to be a very
unfortunate dynamic between both Tom and Andrew. But if one is annoyed
about someone's communication style I think it's much better to ignore
that person or publically lash out about it. Essentially blocking
progress of a patch for months is in my opinion a poor way of handling
it.

If Tom had said a couple months, or even weeks, ago that he doesn't have
time to look into the patch in the 9.5 cycle, I'd not even think about
pressing forward with the patch at this time of the cycle after it had
just undergone significant changes. I like to think that it would have
already gotten in at that point, but who knows. But either way, we're
not in normal circumstances with regard to this patch.

Our community has a reputation, and increasingly so, of being very
painful to work with. Given the growth in adoption, without a
corresponding growth in experienced long term contributors, I don't
think we can afford feeding that reputation with more justified
causes. We have difficulties keeping up even today.

If the patch were in a bad shape I wouldn't even consider pressing
ahead. But I don't think it is anymore. It's also not a patch that has
the danger to destabilize postgres in the longer term. The code is
fairly specific to grouping sets. Doesn't change the disk format. If we
in hindsight discover the implementation wasn't using the right approach
we can just change it. The worst that will happen is that explain output
changes. I think many, much more dangerous, patches have been
integreated into 9.5 with less review.

Andres