extend JSON_TABLE top level path expression - Mailing list pgsql-hackers

From jian he
Subject extend JSON_TABLE top level path expression
Date
Msg-id CACJufxFvUppPZTSfdFof4aKBSYhgAdLhEJUiJPitBj+vcTh+Xg@mail.gmail.com
Whole thread Raw
Responses Re: extend JSON_TABLE top level path expression
List pgsql-hackers
hi.

now you can
SELECT * FROM JSON_TABLE(jsonb '{"a": 123}', '$' || '.' || 'a' COLUMNS
(foo int PATH '$'));

previously, top level path expression (in the above example ('$' || '.' || 'a'))
is hard coded as String A_Const. see gram.y:

if (!IsA($5, A_Const) ||
    castNode(A_Const, $5)->val.node.type != T_String)
    ereport(ERROR,
            errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
            errmsg("only string constants are supported in JSON_TABLE
path specification"),
            parser_errposition(@5));

with the attached patch, this restriction is removed.
but JSON_TABLE COLUMN path expression is still required as String constant.
(maybe we can do the same but that requires grammar changes).

In transformJsonTable:
``tf->docexpr = transformExpr(pstate, (Node *) jfe, EXPR_KIND_FROM_FUNCTION);``

already did the parse analytics job for top level path expression, the same way
as JSON_QUERY.
we just need to take care of initializing and evaluating the top level path
expression.


--
jian
https://www.enterprisedb.com/

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Move WAL/RMGR sequence code into its own file and header
Next
From: Amul Sul
Date:
Subject: Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp