Re: SQL/JSON features for v15

[Jonathan S. Katz]

On 8/10/22 11:50 AM, Andrew Dunstan wrote:

On 2022-08-09 Tu 16:58, Jonathan S. Katz wrote:

Hi,

(Personal hat, not RMT hat unless otherwise noted).

This thread[1] raised some concerns around the implementation of the
SQL/JSON features that are slated for v15, which includes an
outstanding open item[2]. Given the current state of the discussion,
when the RMT met on Aug 8, they several options, readable here[3].
Given we are now into the later part of the release cycle, we need to
make some decisions on how to proceed with this feature given the
concerns raised.

Per additional discussion on the thread, the group wanted to provide
more visibility into the discussion to get opinions on how to proceed
for the v15 release.

Without rehashing the thread, the options presented were:

1. Fixing the concerns addressed in the thread around the v15 SQL/JSON
features implementation, noting that this would likely entail at least
one more beta release and would push the GA date past our normal
timeframe.

2. Try to commit a subset of the features that caused less debate.
This was ruled out.

3. Revert the v15 SQL/JSON features work.

<RMT hat>
Based on the current release timing and the open issues presented on
the thread, and the RMT had recommended reverting, but preferred to
drive consensus on next steps.
</RMT hat>

 From a release advocacy standpoint, I need about 6 weeks lead time to
put together the GA launch. We're at the point where I typically
deliver a draft release announcement. From this, given this involves a
high visibility feature, I would want some clarity on what option we
would like to pursue. Once the announcement translation process has
begun (and this is when we have consensus on the release
announcement), it becomes more challenging to change things out.

 From a personal standpoint (restating from[3]), I would like to see
what we could do to include support for this batch of the SQL/JSON
features in v15. What is included looks like it closes most of the gap
on what we've been missing syntactically since the standard was
adopted, and the JSON_TABLE work is very convenient for converting
JSON data into a relational format. I believe having this feature set
is important for maintaining standards compliance, interoperability,
tooling support, and general usability. Plus, JSON still seems to be
pretty popular.

We're looking for additional input on what makes sense as a best
course of action, given what is presented in[3].

To preserve options I will start preparing reversion patches. Given
there are I think more than 20 commits all told that could be fun, and
will probably take me a little while. The sad part is that to the best
of my knowledge this code is producing correct results, and not
disturbing the stability or performance of anything else. There was a
performance issue but it's been dealt with AIUI.

* adding design docs
* simplifying the type-coercion code
* another other design concerns that were presented



Thanks,

Jonathan

Personally, I hope we don't need to revert. If everything from the open item standpoint is addressed, I want to ensure we capture and complete the remaining issues that were raised on the other thread, i.e. We switched this discussion out to a different thread to get some more visibility on the issue and see if other folks would weigh in. Thus far, there has not been much additional say either way. It would be good if other folks chimed in.

OpenPGP_signature
Description: OpenPGP digital signature