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 15:34:53 |
Message-ID: | CAHgHdKubGHcJiZ6iVoBty5FwF4f+3uE0M00Er4tTsh4_LaH_xw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Mar 4, 2025 at 6:05 AM Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
wrote:
> 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 should mention that
+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]}
+NOTICE: [{"": [[3]]}, [6], [2], "bCi"]
+NOTICE: [2]
works fine. I guess that is good enough. Should we add these to the
sql/jsonb.sql to document the expected behavior, both with the error when
using plain "a" and with the correct output when using "(a)"? The reason I
mention this is that the plpgsql parser might get changed at some point,
and without a test case, we might not notice if this breaks.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Trey Boudreau | 2025-03-04 15:57:41 | Re: Allow LISTEN on patterns |
Previous Message | Peter Eisentraut | 2025-03-04 15:29:08 | Re: Next commitfest app release is planned for March 18th |