From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: "Jonathan S. Katz" <jkatz@postgresql.org>,
        Andres Freund <andres@anarazel.de>,
        Robert Haas <robertmhaas@gmail.com>,
        Nikita Glukhov <n.gluhov@postgrespro.ru>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Michael Paquier <michael@paquier.xyz>,
        John Naylor <john.naylor@enterprisedb.com>,
        Amit Langote <amitlangote09@gmail.com>
Subject: Re: SQL/JSON features for v15
In-reply-to: <dcb47175-d9e2-57be-4f41-aab1cb5c20de@dunslane.net>
References: <20220815223853.itrlpqgpqheg6r6a@awork3.anarazel.de>
 <225d341b-f310-eed0-ceff-b8ec61669d9f@postgrespro.ru>
 <20220816021425.5sa6gx67zmpou3bc@awork3.anarazel.de>
 <8d0ffc54-469a-ffab-68a3-8b547e24a08d@postgresql.org>
 <7d83684b-7932-9f29-400b-0beedfafcdd4@postgrespro.ru>
 <69022273-e7e3-6d1a-10f8-d1b4740e4b97@postgresql.org>
 <92cab50c-152b-84fc-fd49-12b936113a3d@postgresql.org>
 <CA+TgmoaAZq6rRdVA65PBXBKs=jUHhf42Jf78kBLOaX3c6J7MfQ@mail.gmail.com>
 <692364.1661267311@sss.pgh.pa.us>
 <35468585-e18f-3be6-a228-4ec478f796ac@postgresql.org>
 <20220823172617.4oxozbuu7eeprcmh@awork3.anarazel.de>
 <78040b98-83c8-7eb0-54c0-24ce48c487d9@postgresql.org>
 <dcb47175-d9e2-57be-4f41-aab1cb5c20de@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Tue, 23 Aug 2022 15:45:01 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <769711.1661284836.1@sss.pgh.pa.us>
Date: Tue, 23 Aug 2022 16:00:36 -0400
Message-ID: <769712.1661284836@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/769712.1661284836%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
> On 2022-08-23 Tu 15:32, Jonathan S. Katz wrote:
>> On 8/23/22 1:26 PM, Andres Freund wrote:
>>> We could decide to revert this for 15, but leave it in tree for HEAD.

>> If it comes to that, I think that is a reasonable suggestion so long
>> as we're committed to making the requisite changes.

I'm not particularly on board with that.  In the first place, I'm
unconvinced that very much of the current code will survive, and
I don't want people contorting the rewrite in order to salvage
committed code that would be better off junked.  In the second
place, if we still don't have a shippable feature in a year, then
undoing it again is going to be just that much harder.

> One good reason for this is that way we're not fighting against the node
> changes, which complicate any reversion significantly.

Having said that, I'm prepared to believe that a lot of the node
infrastructure won't change because it's dictated by the SQL-spec
grammar.  So we could leave that part alone in HEAD; at worst
it adds some dead code in backend/nodes.

			regards, tom lane