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

From Robert Haas
Subject Re: SQL/JSON features for v15
Date
Msg-id CA+TgmoaM1LeGZw58cxSHXFJuejp-Sw6W7jzwHjZjq2+J5bQQaA@mail.gmail.com
Whole thread Raw
In response to Re: SQL/JSON features for v15  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Responses Re: SQL/JSON features for v15
Re: SQL/JSON features for v15
Re: SQL/JSON features for v15
List pgsql-hackers
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. 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.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Tracking last scan time
Next
From: Andres Freund
Date:
Subject: Re: SQL/JSON features for v15