| From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> | 
| Cc: | Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com> | 
| Subject: | Re: SQL/JSON features for v15 | 
| Date: | 2022-08-23 17:18:49 | 
| Message-ID: | 35468585-e18f-3be6-a228-4ec478f796ac@postgresql.org | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 8/23/22 11:08 AM, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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.
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.
Thanks,
Jonathan
[1] https://wiki.postgresql.org/wiki/Release_Management_Team
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-08-23 17:23:50 | Re: SQL/JSON features for v15 | 
| Previous Message | Nathan Bossart | 2022-08-23 17:15:46 | Re: [PATCH] Optimize json_lex_string by batching character copying |