Horton

Re: SQL/JSON features for v15

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "Jonathan S. Katz" <jkatz@postgresql.org>, Nikita Glukhov <n.gluhov@postgrespro.ru>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andrew Dunstan <andrew@dunslane.net>, Michael Paquier <michael@paquier.xyz>, John Naylor <john.naylor@enterprisedb.com>, Amit Langote <amitlangote09@gmail.com>
Date: 2022-08-23T15:08:31Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@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.  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.

			regards, tom lane

Commits

  1. JSON_TABLE: Add support for NESTED paths and columns

  2. Add basic JSON_TABLE() functionality

  3. Add SQL/JSON query functions

  4. Add soft error handling to some expression nodes

  5. Adjust populate_record_field() to handle errors softly

  6. Refactor code used by jsonpath executor to fetch variables

  7. Add more SQL/JSON constructor functions

  8. SQL/JSON: support the IS JSON predicate

  9. SQL/JSON: add standard JSON constructor functions

  10. Revert SQL/JSON features

  11. Numeric error suppression in jsonpath