Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1utHFU-003zIz-Ly for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Sep 2025 02:59:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1utHFT-001jd0-UA for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Sep 2025 02:59:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1utHFT-001jcr-Jh for pgsql-hackers@lists.postgresql.org; Tue, 02 Sep 2025 02:59:56 +0000 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1utHFQ-0006VT-21 for pgsql-hackers@postgresql.org; Tue, 02 Sep 2025 02:59:55 +0000 Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-b47175d02dcso4181034a12.3 for ; Mon, 01 Sep 2025 19:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756781991; x=1757386791; darn=postgresql.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=UpyrqNJWycNlarCDJqqDKBJJoTAt+Sjm8sJlBgy18/U=; b=AhqoaKJXuL5lQqKC4C6tcXz1urWnTekPiPlxcyRWreA+feekw9pkaRzhtnzIqtpTWX O6OLutyb1xDSCqZryybHhx2XmJ8PIxetEYo47skZNMEXRRaAAUDmv78Lbo4ooZVJxEYP giuDjkbxfjFDl2TjUR2XiZRbqqWSLRjFRrQtyJn439wcvIfzkF++rax+yCD1BGOl6K7r XoLo4Pb8R3MKlAxfAKWI0OBzXFcJwWX/a57wnSB3ozcZRs9+3U+4HpiyrQUFETkabRbG KEsBtdqyI+aVLt3n4eaScgJfQDKk0dPXQQlkJFBeoR0d8JNx6+dU5YW/ngZQrYt6+GX4 zFng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756781991; x=1757386791; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UpyrqNJWycNlarCDJqqDKBJJoTAt+Sjm8sJlBgy18/U=; b=bbFPFI3h+b9R9l/7ZeuoKPO8h6TqpVWQqWJ8zpVcNzQ/kpGZ/is45lygiscyG+5O3D wFO0j5oBKIXevxlllejQ9jpFB9SgXmPhZS4I15p+r3enYWQZ/464lZlNguzQLn7gg6L7 nvFlNkGZtBCg9lzKqRxmGKJcMrifDzmZPXqYVrKlHRVFPjF5q9YXPMSw/hVc1YFIodWK RcODWp/rp9woua1g20w4GwW3DowPvrEwaW/dyqN67mNOwhSW0/jkp5uI+tcIVUy4IszK gIywtG321zvjwCqqyYBGZnlPKJOtd0haIB+3rG53c52xmOfohRn/Ij1K2+Q2vGoZbsfn 4Jsw== X-Forwarded-Encrypted: i=1; AJvYcCWfGN+r2CWnHyCqBIyM2tcZKTWDbcigbdvi+aDysEvcI18tMQK1P3uvCKyQYkKH78qyNq5PaxU644AONjEs@postgresql.org X-Gm-Message-State: AOJu0YzRZRBJFY3SHMDuaMFvEg0K63hhGmB8E6NggMInutWrs3al+KQg 2OWnrzCNviBZfOdHtJaDLKnzJNyIBpbILJH/p4OjfETuSQJBK3C1WsoNA/eNfTDWz7r/TZF0 X-Gm-Gg: ASbGncvyCPp/SD15XHLFkozcy39Y6vcA9jN+HHOE6VAKyozKk1+Iz82B0LkgXM6dWQ8 gs2zfBX2wWZ8XXKbs0O7N+kei/2FKc+HNEEmgckqB4puLa0Wa7bP4+EAu19EC/CJF8Vghy624FQ rgNxEGMvwAEmtdGKyYum2HhX2zx23o6XSIsRJm0Q7IFxGIXlopB8+5LuYO+5WxDEZ7HKmoJMQQb SI0Gqrp1VZRESXyDUEKSaLCo8XvYjM5QmDg5cKhn3aqFr3Eo6seZxyQ1CfoATvYNt23BJiWrBig UTqZasRjVXg8G5k1cLATl5Dpkiyzi9kTWZxrBEEmXcs8jQ9V73iqJyRMIOoRD+cLRrvGeSzhWzD kxAtYdACXBdV/I7sYFicQvCA7qReKEvfo X-Google-Smtp-Source: AGHT+IG4zzKUXGNiM84+iXv+ESKke2qdWM45hIpiLvQtLQ2bhpjhrkyXyM+rJJagiIkptBOLd+8Enw== X-Received: by 2002:a05:6a21:32a7:b0:23f:f4df:6ce3 with SMTP id adf61e73a8af0-243d6e01f60mr13219835637.18.1756781991442; Mon, 01 Sep 2025 19:59:51 -0700 (PDT) Received: from smtpclient.apple ([142.171.105.12]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-327771c31e6sm9215844a91.5.2025.09.01.19.59.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Sep 2025 19:59:50 -0700 (PDT) From: Chao Li Message-Id: <98C6F445-773B-4C82-8198-7F5CD56D5252@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_587B939A-3471-45FA-A487-BC6DCA14A0EE" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: SQL:2023 JSON simplified accessor support Date: Tue, 2 Sep 2025 10:59:39 +0800 In-Reply-To: <290418A2-3A9B-4304-AAAD-4A40CFF1CB93@gmail.com> Cc: jian he , Nikita Malakhov , Vik Fearing , Mark Dilger , Matheus Alcantara , Peter Eisentraut , Andrew Dunstan , Nikita Glukhov , PostgreSQL Hackers , "David E. Wheeler" To: Alexandra Wang References: <21fa36b4-6d56-4556-b524-9e3955b922c8@eisentraut.org> <290418A2-3A9B-4304-AAAD-4A40CFF1CB93@gmail.com> X-Mailer: Apple Mail (2.3826.700.81) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --Apple-Mail=_587B939A-3471-45FA-A487-BC6DCA14A0EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 29, 2025, at 15:22, Chao Li wrote: >=20 > +static bool > +jsonb_check_jsonpath_needed(List *indirection) > +{ > + ListCell *lc; > + > + foreach(lc, indirection) > + { > + Node *accessor =3D lfirst(lc); > + > + if (IsA(accessor, String)) > + return true; >=20 > Like I mentioned in my previous comment, if we convert String (dot = notation) to Indices in rewritten phase, then jsonpath might be no = longer needed, and the code logic is much simplified. >=20 Taking back this comment. As Alex explained in the other email, dot = notation and indices accessor are different. >=20 > --- 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 =3D lfirst_node(A_Indices, idx); >=20 > Should this foreach be pull up to out of = transformContainerSubscripts()? Originally = transformContainerSubscripts() runs only once, but now it=E2=80=99s = 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 =3D initial_node(A_Indices, *indirection); If (list_length(*indirection) !=3D 1 || ai->is_slice) { ereport(=E2=80=A6) } ``` jsonbsubs doesn=E2=80=99t need to check is_slice flag as well, I will = explain that in my next email tougher with my new comments. So that, =E2=80=9Cbool isSlace=E2=80=9D can be removed from = SubscriptTransform, and let every individual subs check is_slice. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/ --Apple-Mail=_587B939A-3471-45FA-A487-BC6DCA14A0EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 29, 2025, at 15:22, Chao Li = <li.evan.chao@gmail.com> wrote:

+static = bool
+jsonb_check_jsonpath_needed(List = *indirection)
+{
+       ListCell =   *lc;
+
+       foreach(lc, = indirection)
+       {
+   =             Node       = *accessor =3D lfirst(lc);
+
+       =         if (IsA(accessor, String))
+ =                     =   return true;

Like I mentioned = in my previous comment, if we convert String (dot notation) to Indices = in rewritten phase, then jsonpath might be no longer needed, and the = code logic is much simplified.


Taking back this = comment. As Alex explained in the other email, dot notation and indices = accessor are different.


--- = 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 =3D lfirst_node(A_Indices, idx);

Should this = foreach be pull up to out of transformContainerSubscripts()? Originally = transformContainerSubscripts() runs only once, but now it=E2=80=99s = 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 =3D = initial_node(A_Indices, *indirection);
If = (list_length(*indirection) !=3D 1 || = ai->is_slice)
{
    = ereport(=E2=80=A6)
}
```

jsonbsubs = doesn=E2=80=99t need to check is_slice flag as well, I will explain that = in my next email tougher with my new = comments.

So that, =E2=80=9Cbool isSlace=E2=80=9D= can be removed from SubscriptTransform, and let every individual subs check = is_slice.

Best regards,
--
Chao Li (Evan)
HighGo Software = Co., Ltd.
https://www.highgo.com/



= --Apple-Mail=_587B939A-3471-45FA-A487-BC6DCA14A0EE--