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

From jian he
Subject Re: SQL:2023 JSON simplified accessor support
Date
Msg-id CACJufxHsT1pAxY2sihZrOy3C=y6pRx11is-y+jsLL0skTjpx7A@mail.gmail.com
Whole thread Raw
In response to Re: SQL:2023 JSON simplified accessor support  (jian he <jian.universality@gmail.com>)
List pgsql-hackers
On Thu, Jul 10, 2025 at 4:53 PM jian he <jian.universality@gmail.com> wrote:
>
> src7=# select ('{"a": 1, "b": "c", "d": [1, 2, 3]}'::jsonb).d['1'::int8];
> WARNING:  mixed usage of jsonb simplified accessor syntax and jsonb
> subscripting.
> LINE 1: ...t ('{"a": 1, "b": "c", "d": [1, 2, 3]}'::jsonb).d['1'::int8]...
>                                                              ^
> HINT:  use dot-notation for member access, or use non-null integer
> constants subscripting for array access.
> ERROR:  subscript type bigint is not supported
> LINE 1: ...t ('{"a": 1, "b": "c", "d": [1, 2, 3]}'::jsonb).d['1'::int8]...
>                                                              ^
> HINT:  jsonb subscript must be coercible to either integer or text.
>
> The above example looks very bad. location printed twice, hint message
> is different.
> two messages level (ERROR, WARNING).
>
For plainSELECT statement, we have WARNING only in
src/test/regress/expected/xml.out,  src/test/regress/expected/xml_2.out
for example:
SELECT xpath('/*', '<relativens xmlns=''relative''/>');
WARNING:  line 1: xmlns: URI relative is not absolute
<relativens xmlns='relative'/>
                            ^
                xpath
--------------------------------------
 {"<relativens xmlns=\"relative\"/>"}
(1 row)

so i am not sure a plain SELECT statement issuing WARNING is appropriate.
------------------------------------------
in jsonb_subscript_make_jsonpath we have
    foreach(lc, *indirection)
{
        if (IsA(accessor, String))
            ....
        else if (IsA(accessor, A_Indices))
        else
            /*
             * Unsupported node type for creating jsonpath. Instead of
             * throwing an ERROR, break here so that we create a jsonpath from
             * as many indirection elements as we can and let
             * transformIndirection() fallback to alternative logic to handle
             * the remaining indirection elements.
             */
              break;
}
the above ELSE branch comments look suspicious to me.
transformIndirection->transformContainerSubscripts->jsonb_subscript_transform->jsonb_subscript_make_jsonpath
As you can see, transformIndirection have a long distance from
jsonb_subscript_make_jsonpath,
let transformIndirection handle remaining indirection elements seems not good.

if you look at src/backend/parser/gram.y line 16990.
transformIndirection(ParseState *pstate, A_Indirection *ind)
ind->indirection can be be Node of String, A_Indices, A_Star

also the above ELSE branch never reached in regress tests.
------------------------------------------

typedef struct FieldAccessorExpr
{
    Expr        xpr;
    char       *fieldname;        /* name of the JSONB object field accessed via
                                 * dot notation */
    Oid            faecollid pg_node_attr(query_jumble_ignore);
    int            location;
}            FieldAccessorExpr;

first field as NodeTag should be just fine?
I am not sure the field "location" is needed now, if it is needed, it should be
type as ParseLoc.
we should add it to src/tools/pgindent/typedefs.list



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Problem with transition tables on partitioned tables with foreign-table partitions
Next
From: Melanie Plageman
Date:
Subject: Re: Fix some inconsistencies with open-coded visibilitymap_set() callers