On Thu, 11 Jun 2026 at 11:32, solai v <[email protected]> wrote: > > Hi Jian, > > I reviewed and tested patch v2 . > Before applying the patch JSON_TABLE accepted only literal top-level > patch string such as '$.a' and rejected equivalent path expression > such as '$'||.'a' with: > ERROR :only string constants are supported in JSON_TABLE path specification > After applying the patch ,JSON_TABLE correctly accepts path > expressions and returns the expected results. > I verified cases using string concatenation (e.g. '$' || '.a' and '$' > || '.' || 'a'),,while existing behavior with literal path strings > remained unchanged. > I also confirmed that JSON_QUERY already accepts such patch > expressions,so the patch makes JSON_TABLE behavior more consistent > with other SQL/JSON functions. > The patch applied successfully and tested queries behaved as expected. > Thanks for working on this improvement.
Hi Jian, This needs a rebase. Your code changes: appendStringInfoString(buf, ", "); - get_const_expr(root->path->value, context, -1); + get_rule_expr(jexpr->path_spec, context, showimplicit); appendStringInfo(buf, " AS %s", quote_identifier(root->path->name)); But I can see elsewhere in ruleutils.c, this already exists: get_rule_expr(jexpr->formatted_expr, context, showimplicit); appendStringInfoString(buf, ", "); get_json_path_spec(jexpr->path_spec, context, showimplicit); So should you be using get_json_path_spec() in this case? Also, should there be any documentation changes with this? And given the rules have changed for TableFunc.rowexpr and JsonTablePathScan.path->value, does this need a catversion bump? Thom
