Re: SQL:2023 JSON simplified accessor support

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>
Cc: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Nikita Glukhov <glukhov(dot)n(dot)a(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, "David E(dot) Wheeler" <david(at)justatheory(dot)com>, jian he <jian(dot)universality(at)gmail(dot)com>
Subject: Re: SQL:2023 JSON simplified accessor support
Date: 2025-03-04 14:05:18
Message-ID: CAHgHdKtL9nNaKXGCLt9gWugVzYWKhoBDQ7NESUwdCBty8kFK-A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 3, 2025 at 12:23 PM Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>
wrote:

> I've attached v10, which addresses your feedback.
>
>
Hi Alex! Thanks for the patches.

In src/test/regress/sql/jsonb.sql, the section marked with "-- slices are
not supported" should be relabeled. That comment predates these patches,
and is now misleading.

A bit further down in expected/jsonb.out, there is an expected failure, but
no SQL comment to indicate that it is expected:

+SELECT (t.jb).* FROM test_jsonb_dot_notation;
+ERROR: missing FROM-clause entry for table "t"
+LINE 1: SELECT (t.jb).* FROM test_jsonb_dot_notation;

Perhaps a "-- fails" comment would clarify? Then, further down,

+SELECT (jb).a.**.x FROM test_jsonb_dot_notation; -- not supported
+ERROR: syntax error at or near "**"
+LINE 1: SELECT (jb).a.**.x FROM test_jsonb_dot_notation;

I wonder if it would be better to have the parser handle this case and
raise a ERRCODE_FEATURE_NOT_SUPPORTED instead?

I got curious about the support for this new dot notation in the plpgsql
parser and tried:

+DO $$
+DECLARE
+ a jsonb := '[1,2,3,4,5,6,7]'::jsonb;
+BEGIN
+ WHILE a IS NOT NULL
+ LOOP
+ RAISE NOTICE '%', a;
+ a := a[2:];
+ END LOOP;
+END
+$$ LANGUAGE plpgsql;
+NOTICE: [1, 2, 3, 4, 5, 6, 7]
+NOTICE: [3, 4, 5, 6, 7]
+NOTICE: [5, 6, 7]
+NOTICE: 7

which looks good! But then I tried:

+DO $$
+DECLARE
+ a jsonb := '{"": 6, "NU": [{"": [[3]]}, [6], [2], "bCi"], "aaf": [-6,
-8]}'::jsonb;
+BEGIN
+ WHILE a IS NOT NULL
+ LOOP
+ RAISE NOTICE '%', a;
+ a := COALESCE(a."NU", a[2]);
+ END LOOP;
+END
+$$ LANGUAGE plpgsql;
+NOTICE: {"": 6, "NU": [{"": [[3]]}, [6], [2], "bCi"], "aaf": [-6, -8]}
+ERROR: missing FROM-clause entry for table "a"
+LINE 1: a := COALESCE(a."NU", a[2])
+ ^
+QUERY: a := COALESCE(a."NU", a[2])
+CONTEXT: PL/pgSQL function inline_code_block line 8 at assignment

which suggests the plpgsql parser does not recognize a."NU" as we'd
expect. Any thoughts on this?

I notice there are no changes in src/interfaces/ecpg/test, which concerns
me. The sqljson.pgc and sqljson_jsontable.pgc files are already testing
json handling in ecpg; perhaps just extend those a bit?


Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-03-04 14:10:14 Re: new commitfest transition guidance
Previous Message Andrei Lepikhov 2025-03-04 13:56:40 Re: making EXPLAIN extensible