Re: SQL/JSON features for v15 - Mailing list pgsql-hackers

On 8/31/22 12:26 PM, Robert Haas wrote:
> On Wed, Aug 31, 2022 at 10:20 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
>> Andres, Robert, Tom: With this recent work, have any of your opinions
>> changed on including SQL/JSON in v15?
> 
> No. Nothing's been committed, and there's no time to review anything
> in detail, and there was never going to be.

OK. Based on this feedback, the RMT is going to request that this is 
reverted.

With RMT hat on -- Andrew can you please revert the patchset?

>  Nikita said he was ready
> to start hacking in mid-August. That's good of him, but feature freeze
> was in April. We don't start hacking on a feature 4 months after the
> freeze. I'm unwilling to drop everything I'm working on to review
> patches that were written in a last minute rush. Even if these patches
> were more important to me than my own work, which they are not, I
> couldn't possibly do a good job reviewing complex patches on top of
> other complex patches in an area that I haven't studied in years. And
> if I could do a good job, no doubt I'd find a bunch of problems -
> whether they would be large or small, I don't know - and then that
> would lead to more changes even closer to the intended release date.
> 
> I just don't understand what the RMT thinks it is doing here. When a
> concern is raised about whether a feature is anywhere close to being
> in a releasable state in August, "hack on it some more and then see
> where we're at" seems like an obviously impractical way forward. It
> seemed clear to me from the moment that Andres raised his concerns
> that the only two viable strategies were (1) revert the feature and be
> sad or (2) decide to ship it anyway and hope that Andres is incorrect
> in thinking that it will become an embarrassment to the project. The
> RMT has chosen neither of these, and in fact, really seems to want
> someone else to make the decision. But that's not how it works. The
> RMT concept was invented precisely to solve problems like this one,
> where the patch authors don't really want to revert it but other
> people think it's pretty busted. If such problems were best addressed
> by waiting for a long time to see whether anything changes, we
> wouldn't need an RMT. That's exactly how we used to handle these kinds
> of problems, and it sucked.

This is fair feedback. However, there are a few things to consider here:

1. When Andres raised his initial concerns, the RMT did recommend to 
revert but did not force it. Part of the RMT charter is to try to get 
consensus before doing so and after we've exhausted the community 
process. As we moved closer, the patch others proposed some suggestions 
which other folks were amenable to trying.

Unfortunately, time has run out. However,

2. One of the other main goals of the RMT is to ensure the release ships 
"on time" which we define to be late Q3/early Q4. We factored that into 
the decision making process around this. We are still on time for the 
release.

I take responsibility for the decision making. I would be open to 
discuss this further around what worked / what didn't with the RMT and 
where we can improve in the future.

Thanks,

Jonathan