Re: SQL/JSON features for v15

[Jonathan S. Katz]

On 8/23/22 11:08 AM, Tom Lane wrote:

Robert Haas <robertmh...@gmail.com> writes:

At the end of the day, the RMT is going to have to take a call here.
It seems to me that Andres's concerns about code quality and lack of
comments are probably somewhat legitimate, and in particular I do not
think the use of subtransactions is a good idea. I also don't think
that trying to fix those problems or generally improve the code by
committing thousands of lines of new code in August when we're
targeting a release in September or October is necessarily a good
idea. But I'm also not in a position to say that the project is going
to be irreparably damaged if we just ship what we've got, perhaps
after fixing the most acute problems that we currently know about.

The problem here is that this was going to be a headline new feature
for v15.  Shipping what apparently is only an alpha-quality implementation
seems pretty problematic unless we advertise it as such, and that's

not something we've done very much in the past.

With my user hat on, we have done this before -- if inadvertently -- but agree it's not recommended nor a habit we should get into.

As you say, we've delegated this sort of decision to the RMT, but
if I were on the RMT I'd be voting to revert.

Thanks,

Jonathan

[1] https://wiki.postgresql.org/wiki/Release_Management_Team

With RMT hat on,the RMT does have power of forced commit/revert in absence of consensus through regular community processes[1]. We did explicitly discuss at our meeting today if we were going to make the decision right now. We decided that we would come back and set a deadline on letting the community processes play out, otherwise we will make the decision. For decision deadline: if there is no community consensus by end of Aug 28, 2022 AoE, the RMT will make the decision. I know Andrew has been prepping for the outcome of a revert -- this should give enough for review and merge prior to a Beta 4 release (targeted for Sep 8). If there is concern about that, the RMT can move up the decision timeframe. Taking RMT hat off, if the outcome is "revert", I do want to ensure we don't lose momentum on getting this into v16. I know a lot of time and effort has gone into this featureset and it seems to be trending in the right direction. We have a mixed history on reverts in terms of if/when they are committed and I don't want to see that happen to these features. I do think this will remain a headline feature even if we delay it for v16. I saw Andrew suggest that the controversial parts of the patchset may be severable from some of the new functionality, so I would like to see that proposal and if it is enough to overcome concerns.

OpenPGP_signature
Description: OpenPGP digital signature