Re: SQL:2023 JSON simplified accessor support
Alexandra Wang <alexandra.wang.oss@gmail.com>
From: Alexandra Wang <alexandra.wang.oss@gmail.com>
To: Chao Li <li.evan.chao@gmail.com>
Cc: jian he <jian.universality@gmail.com>,
Nikita Malakhov <hukutoc@gmail.com>, Vik Fearing <vik@postgresfriends.org>,
Mark Dilger <mark.dilger@enterprisedb.com>, Matheus Alcantara <matheusssilv97@gmail.com>,
Peter Eisentraut <peter@eisentraut.org>, Andrew Dunstan <andrew@dunslane.net>, Nikita Glukhov <glukhov.n.a@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
"David E. Wheeler" <david@justatheory.com>
Date: 2025-09-03T02:16:37Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add test coverage for indirection transformation
- 64492917280a 19 (unreleased) landed
-
Fix typo in comment
- 81a61fde84ff 19 (unreleased) landed
-
Implementation of subscripting for jsonb
- 676887a3b0b8 14.0 cited
Attachments
- v15-0007-Implement-jsonb-wildcard-member-accessor.patch (application/octet-stream) patch v15-0007
- v15-0001-Allow-transformation-of-only-a-sublist-of-subscr.patch (application/octet-stream) patch v15-0001
- v15-0004-Extract-coerce_jsonpath_subscript.patch (application/octet-stream) patch v15-0004
- v15-0006-Implement-Jsonb-subscripting-with-slicing.patch (application/octet-stream) patch v15-0006
- v15-0005-Implement-read-only-dot-notation-for-jsonb.patch (application/octet-stream) patch v15-0005
- v15-0003-Export-jsonPathFromParseResult.patch (application/octet-stream) patch v15-0003
- v15-0002-Allow-Generic-Type-Subscripting-to-Accept-Dot-No.patch (application/octet-stream) patch v15-0002
Hi Chao,
Thanks for reviewing! I've attached v15, which addresses your
feedback.
I didn't make all the changes you suggested, please see my individual
comments below and in the next email.
On Mon, Sep 1, 2025 at 7:59 PM Chao Li <li.evan.chao@gmail.com> wrote:
> --- a/src/backend/parser/parse_node.c
> +++ b/src/backend/parser/parse_node.c
> @@ -244,7 +244,7 @@ transformContainerSubscripts(ParseState *pstate,
> Node
> *containerBase,
> Oid containerType,
> int32
> containerTypMod,
> - List *indirection,
> + List
> **indirection,
> bool isAssignment)
> {
> SubscriptingRef *sbsref;
> @@ -280,7 +280,7 @@ transformContainerSubscripts(ParseState *pstate,
> * element. If any of the items are slice specifiers
> (lower:upper), then
> * the subscript expression means a container slice operation.
> */
> - foreach(idx, indirection)
> + foreach(idx, *indirection)
> {
> A_Indices *ai = lfirst_node(A_Indices, idx);
>
> Should this foreach be pull up to out of transformContainerSubscripts()?
> Originally transformContainerSubscripts() runs only once, but now it’s
> placed in a while loop, and every time this foreach needs to go through the
> entire indirection list, which are duplicated computation.
>
>
> After revisiting the code, I think this loop of checking is_slice should
> be removed here.
>
> It seems only arrsubs cares about this is_slice flag.
>
> hstore_subs can only take a single indirection, so it can do a simple
> check like:
>
> ```
> ai = initial_node(A_Indices, *indirection);
> If (list_length(*indirection) != 1 || ai->is_slice)
> {
> ereport(…)
> }
> ```
>
> jsonbsubs doesn’t need to check is_slice flag as well, I will explain that
> in my next email tougher with my new comments.
>
> So that, “bool isSlace” can be removed from SubscriptTransform, and let
> every individual subs check is_slice.
>
I don't like the idea of removing the "bool isSlice" argument from the
*SubscriptTransform() function pointer. This patch series should make
only minimal changes to the subscripting API. While it's true that
each implementation can easily determine the boolean value of isSlice
itself, I don't see a clear benefit to changing the interface. As you
noted, arrsubs cares about isSlice; and users can also define custom
data types that support subscripting, so the interface is not limited
to built-in types.
As the comment for *SubscriptTransform() explains:
> (Of course, if the transform method
> * does not care to support slicing, it can just throw an error if isSlice.)
It's possible that in the end the "isSlice" argument isn't needed at
all, but I don’t think this patch set is the right place for that
refactor.
Best,
Alex