Re: SQL/JSON features for v15

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Amit Langote <amitlangote09(at)gmail(dot)com>, Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Subject: Re: SQL/JSON features for v15
Date: 2022-08-31 16:04:44
Message-ID: 4151123.1661961884@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2022-08-31 10:20:24 -0400, Jonathan S. Katz wrote:
>> Andres, Robert, Tom: With this recent work, have any of your opinions
>> changed on including SQL/JSON in v15?

> I don't really know what to do here. It feels blatantly obvious that this code
> isn't even remotely close to being releasable. I'm worried about the impact of
> the big revert at this stage of the release cycle, and that's not getting
> better by delaying further. And I'm getting weary of being asked to make the
> obvious call that the authors of this feature as well as the RMT should have
> made a while ago.

I have to agree. There is a large amount of code at stake here.
We're being asked to review a bunch of hastily-produced patches
to that code on an even more hasty schedule (and personally
I have other things I need to do today...) I think the odds
of a favorable end result are small.

> From my POV the only real discussion is whether we'd want to revert this in 15
> and HEAD or just 15. There's imo a decent point to be made to just revert in
> 15 and aggressively press forward with the changes posted in this thread.

I'm not for that. Code that we don't think is ready to ship
has no business being in the common tree, nor does it make
review any easier to be looking at one bulky set of
already-committed patches and another bulky set of deltas.

I'm okay with making an exception for the include/nodes/ and
backend/nodes/ files in HEAD, since the recent changes in that
area mean it'd be a lot of error-prone work to produce a reverting
patch there. We can leave those in as dead code temporarily, I think.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-08-31 16:08:39 Re: [PATCH] Query Jumbling for CALL and SET utility statements
Previous Message Reid Thompson 2022-08-31 16:03:06 Add tracking of backend memory allocated to pg_stat_activity