Re: SQL:2023 JSON simplified accessor support - Mailing list pgsql-hackers

From Alexandra Wang
Subject Re: SQL:2023 JSON simplified accessor support
Date
Msg-id CAK98qZ1XFee_x1uQFcwJkZCSVcPBy-A1ib3N5Ls2uDdZviKVOw@mail.gmail.com
Whole thread Raw
In response to Re: SQL:2023 JSON simplified accessor support  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: SQL:2023 JSON simplified accessor support
Re: SQL:2023 JSON simplified accessor support
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Add support for specifying tables in pg_createsubscriber.
Next
From: Alexandra Wang
Date:
Subject: Re: SQL:2023 JSON simplified accessor support