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 1uwC3r-007EkF-Py for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Sep 2025 04:04:00 +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 1uwC3q-00GWOW-MP for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Sep 2025 04:03:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uwC3q-00GWOM-8u for pgsql-hackers@lists.postgresql.org; Wed, 10 Sep 2025 04:03:58 +0000 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uwC3o-001aho-0P for pgsql-hackers@postgresql.org; Wed, 10 Sep 2025 04:03:57 +0000 Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-32bab30eefbso224223a91.1 for ; Tue, 09 Sep 2025 21:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757477035; x=1758081835; 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=H5HaEZphQw+j9TYKBPjtnb0v/A9yPF/3Ft6ezYrQQi0=; b=D+KqkSjL9HZMwfmjssCQ3Dc72kTM3HT/CxJcFIbJMNLFCPgbm1u2NulduKYV13Dx5/ sLLOACx007K4k225pGxHW2c8HS+3jt8Mb2hF0hNzfT2Y7gWz54e7LibvtHVJQ4apwwjh +gehVwfn/ifIkldAeBeTZvYZqEykbDNI4a58Jh9yY5yrgZiYifAkRzRa7WOUb4yhkBKb Avst7QvVF6Pbz8DlxLkoMdr27wuRGpZ+4kn1Q8bgaf31hT0Fu6OcXCwstf5yDVasqSHq t8tttJx2krl9TTqzVZNRCZ4ymgSyWydvyVFZu5X5kUcZkljnQTzfH4HcN3S+LvUtCIa+ 5lVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757477035; x=1758081835; 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=H5HaEZphQw+j9TYKBPjtnb0v/A9yPF/3Ft6ezYrQQi0=; b=pwlepyCiYLCWII51ZLkP8rv3NWBMtH8AIJVjbe+JWDCAnEgC8nFU8DEeKaW9YPsXps nR4TaCZn7q8/rfBN8iVVSBPewT4cOYfRR6CWQUiZCijcbCkGPSmOfsXpLpW1pGqmwQn/ DZ5nhQCeTyYeO/5CRU0xu/gyZ2AX55ZcuONIuf6byqJNiqxUF8s5AKYKoiYTiGtBO1Ov PEnaQywayCClQcNfihc/Y/7FXXAljejoN8FpBdUIUFiBkXXn4ITjj2h3IiwnfgXWxwOt 4zXkl+R00nRg6JwO9jW9D3042N4atXKL/m549YWoLtUTyobhbpRS/SNirzjvo1lIkkko SbRA== X-Forwarded-Encrypted: i=1; AJvYcCWgDEioczBboF9NryM4GtHrZUdO2iQL9KHOibIRJelTkl6dhz1IstL03FCpS0c1L3sAI1edcxCdhyN3Y6WY@postgresql.org X-Gm-Message-State: AOJu0Yyg6v29efWPfhgZMAsWHZDYTGuXyRVWUlh8e8+xpPLIqSu/l0zt WOcsfxktrkdb8DiPbLgzXywwbvjpZc4G9n7gsKPcuw1AWn6ecBCdt/41 X-Gm-Gg: ASbGnct3uFTshAXTOURGpPDD4ametslV+7fxc9Y2TwUX6TJ4QflS9mA+R02K7Tu3TVx n6ye2lQItuqeBjw1jYVF5o7BgXUgE20M7u9LAJAgXSMGQRgpTadcKq6fWwx0WYNZOgzxmPvjp3g NzRzncp1F82acmqTOygGz0p8oIX1xi6uB56LU2NhNG4qFAX3/mD5ENB1qsqMoirTafD5jvgX9Nl KKF00zQyzsMt0rDnq8FdL86XnZbNWbPOnLj9fyR6LUo+HgoMzgxRsH2l03Qz4tXJdMq3vU/FwSo wAhjsYYn7/tZ9ic3keGD0koZVWMyTBM9sBkS495HInbWBDksaA7rnmk+73hLDJy/1F0l3ukDGIz XyniCaLzUEWnxjnluqftrgfS41W0iJuo9 X-Google-Smtp-Source: AGHT+IFiGALndX7Gh/rM5kQ5/9C2JmY43hskzE2bvfTFROwv15My6cPeYzzPloGcF+RYSmy55hv7Aw== X-Received: by 2002:a17:903:2f81:b0:240:5bf7:97ac with SMTP id d9443c01a7336-24cef527904mr217996135ad.16.1757477034750; Tue, 09 Sep 2025 21:03:54 -0700 (PDT) Received: from smtpclient.apple ([142.171.105.12]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-25a2a921755sm12647545ad.96.2025.09.09.21.03.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Sep 2025 21:03:54 -0700 (PDT) From: Chao Li Message-Id: <8CB9A1EC-2D14-44FF-A600-6669353A14C2@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5DB282BB-AA24-4D9F-8A0A-7A25EC966B9A" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) Subject: Re: SQL:2023 JSON simplified accessor support Date: Wed, 10 Sep 2025 12:03:36 +0800 In-Reply-To: Cc: Nikita Glukhov , jian he , Nikita Malakhov , Vik Fearing , Mark Dilger , Matheus Alcantara , Peter Eisentraut , Andrew Dunstan , PostgreSQL Hackers , "David E. Wheeler" To: Alexandra Wang References: <21fa36b4-6d56-4556-b524-9e3955b922c8@eisentraut.org> <290418A2-3A9B-4304-AAAD-4A40CFF1CB93@gmail.com> <98C6F445-773B-4C82-8198-7F5CD56D5252@gmail.com> <052E941B-C905-448F-AE3A-753C12AAC938@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=_5DB282BB-AA24-4D9F-8A0A-7A25EC966B9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 10, 2025, at 07:53, Alexandra Wang = wrote: >=20 > I think this (jb)[0] case is rather trivial. However, since it's been > behaving the pre-standard way since PG14, I hesitate to change the > existing behavior as part of my patches, and I feel it could be a > bikeshedding kind of discussion in a separate thread.=20 I am fine to retain the PG14 behavior. But the confusion part is: ``` evantest=3D# select ('{"name": "Alice", "birthday": {"year": 2000, = "month": 8}}'::jsonb)[0]['birthday']['year']; jsonb ------- (1 row) evantest=3D# select ('{"name": "Alice", "birthday": {"year": 2000, = "month": 8}}'::jsonb)[0]['birthday'].year; year ------ 2000 (1 row) ``` As long as the expression containing a dot notation, =E2=80=9C[0]=E2=80=9D= behaves differently from PG14. I agree we should not recommend the mixed usages of `[`a`]` and `.a`, = but we haven=E2=80=99t prevented from that. Given they are different = meanings, `[=E2=80=98a=E2=80=99]` implies strict mode and `.a` implies = lax mode, for a complex JSON object, users may intentionally mix use = both, which sounds reasonable. I don=E2=80=99t see you have updated any documentation yet. I don=E2=80=99= t want to block you because of this issue. As long as you state the = behavior clearly in the document, I am happy to let it go. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/ --Apple-Mail=_5DB282BB-AA24-4D9F-8A0A-7A25EC966B9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 10, 2025, at 07:53, Alexandra Wang = <alexandra.wang.oss@gmail.com> wrote:

I think this (jb)[0] case is rather = trivial. However, since it's been
behaving the pre-standard way since PG14, I hesitate to = change the
existing behavior as = part of my patches, and I feel it could be a
bikeshedding kind of discussion in a = separate = thread. 

I am = fine to retain the PG14 behavior. But the confusion part = is:

```
evantest=3D# select = ('{"name": "Alice", "birthday": {"year": 2000, "month": = 8}}'::jsonb)[0]['birthday']['year'];
 jsonb
-----= --

(1 row)

evantest=3D# = select ('{"name": "Alice", "birthday": {"year": 2000, "month": = 8}}'::jsonb)[0]['birthday'].year;
 year
------
 2000
(1 = row)
```

As long as the = expression containing a dot notation, =E2=80=9C[0]=E2=80=9D behaves = differently from PG14.

I agree we should not = recommend the mixed usages of `[`a`]` and `.a`, but we haven=E2=80=99t = prevented from that. Given they are different meanings, `[=E2=80=98a=E2=80= =99]`  implies strict mode and `.a` implies lax mode, for a complex = JSON object, users may intentionally mix use both, which sounds = reasonable.

I don=E2=80=99t see you have = updated any documentation yet. I don=E2=80=99t want to block you because = of this issue. As long as you state the behavior clearly in the = document, I am happy to let it go.

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




= --Apple-Mail=_5DB282BB-AA24-4D9F-8A0A-7A25EC966B9A--