Re: SQL/JSON features for v15

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, 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>, 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 15:29:39
Message-ID: 09803357-fec3-9332-8b6c-7a331c3e5bf1@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 2022-08-23 Tu 11:08, 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. I also wonder how
> much any attempts at fixing it later would be constrained by concerns
> about compatibility with the v15 version.
>
>> ... And we do have other bad code in the system.
> Can't deny that, but a lot of it is legacy code that we wish we could
> rip out and can't because backwards compatibility. This is not legacy
> code ... not yet anyway.
>
> 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.
>
>

I know I previously said that this was not really severable, but I've
started having second thoughts about that. If we disabled as Not
Implemented the DEFAULT form of the ON ERROR and ON EMPTY clauses, and
possibly the RETURNING clause in some cases, it's possible we could get
rid of most of what's been controversial. That could still leave us a
good deal of what we want, including JSON_TABLE, which is by far the
most interesting of these features. I haven't looked closely yet at how
possible this is, it only occurred to me today, but I think it's worth
exploring.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Полина Бунгина 2022-08-23 15:46:30 pg_rewind WAL segments deletion pitfall
Previous Message Andres Freund 2022-08-23 15:27:05 Re: SQL/JSON features for v15