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

From Chao Li
Subject Re: SQL:2023 JSON simplified accessor support
Date
Msg-id 8CB9A1EC-2D14-44FF-A600-6669353A14C2@gmail.com
Whole thread Raw
In response to Re: SQL:2023 JSON simplified accessor support  (Alexandra Wang <alexandra.wang.oss@gmail.com>)
List pgsql-hackers


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=# select ('{"name": "Alice", "birthday": {"year": 2000, "month": 8}}'::jsonb)[0]['birthday']['year'];
 jsonb
-------

(1 row)

evantest=# 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, “[0]” behaves differently from PG14.

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

I don’t see you have updated any documentation yet. I don’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/




pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: SQL:2023 JSON simplified accessor support
Next
From: Florents Tselai
Date:
Subject: Re: PostgreSQL 18 GA press release draft