feat(expr): support #> and #>> operator for extracting jsonb at a path

[wangrunji0408]

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

This PR adds support for jsonb path extraction:

jsonb #> text[] → jsonb
jsonb #>> text[] → text

Checklist

• I have written necessary rustdoc comments
• I have added necessary unit tests and integration tests
• I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
• My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
• All checks passed in ./risedev check (or alias, ./risedev c)
• My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

• My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

• My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

support the following operators:

jsonb #> text[] → jsonb
Extracts JSON sub-object at the specified path, where path elements can be either field keys or array indexes.
'{"a": {"b": ["foo","bar"]}}'::json #> '{a,b,1}' → "bar"

jsonb #>> text[] → text
Extracts JSON sub-object at the specified path as text.
'{"a": {"b": ["foo","bar"]}}'::json #>> '{a,b,1}' → bar

[xiangjinwu]

Limitations:

SELECT '{"a":"b","c":[1,2,3]}'::jsonb #> '{0}';

such queries will output different results than postgres, because the literal {0} is interpreted as text but not text[] by default. I don't know how pg handles this case.

My bad ... If we do not reuse JsonbAccessInner / JsonbAccessStr but introduce new ExprType in proto, it would work "automatically". text has an advantage during overloads resolution, and maybe that's the reason PostgreSQL introduces #> rather than overloads ->.

That being said, it is generally preferred to use the array[] constructor syntax despite being a little bit more verbose.

[wangrunji0408]

Limitations:

SELECT '{"a":"b","c":[1,2,3]}'::jsonb #> '{0}';

such queries will output different results than postgres, because the literal {0} is interpreted as text but not text[] by default. I don't know how pg handles this case.

My bad ... If we do not reuse JsonbAccessInner / JsonbAccessStr but introduce new ExprType in proto, it would work "automatically"

soga. I'll add new expr types.

[codecov]

Codecov Report

Merging #13110 (88202df) into main (dd3d59a) will increase coverage by 0.05%.
Report is 16 commits behind head on main.
The diff coverage is 7.69%.

@@            Coverage Diff             @@
##             main   #13110      +/-   ##
==========================================
+ Coverage   68.25%   68.31%   +0.05%     
==========================================
  Files        1498     1498              
  Lines      252714   252748      +34     
==========================================
+ Hits       172501   172670     +169     
+ Misses      80213    80078     -135     

Flag	Coverage Δ
rust	68.31% <7.69%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
src/frontend/src/binder/expr/function.rs	78.51% <100.00%> (ø)
src/frontend/src/expr/pure.rs	87.69% <ø> (ø)
src/frontend/src/binder/expr/binary_op.rs	74.19% <33.33%> (-1.64%)	⬇️
src/common/src/types/jsonb.rs	36.76% <0.00%> (-0.83%)	⬇️
src/expr/impl/src/scalar/jsonb_access.rs	0.00% <0.00%> (ø)

... and 19 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more