| From: | jian he <jian(dot)universality(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | extend JSON_TABLE top level path expression |
| Date: | 2025-11-28 04:09:17 |
| Message-ID: | CACJufxFvUppPZTSfdFof4aKBSYhgAdLhEJUiJPitBj+vcTh+Xg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-extend-JSON_TABLE-top-level-path-expression.patch | text/x-patch | 43.3 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amul Sul | 2025-11-28 04:16:43 | Re: Refactoring: Use soft error reporting for *_opt_overflow functions of date/timestamp |
| Previous Message | Michael Paquier | 2025-11-28 04:05:55 | Re: Move WAL/RMGR sequence code into its own file and header |