Re: extend JSON_TABLE top level path expression

On Thu, 11 Jun 2026 at 11:32, solai v <solai(dot)cdac(at)gmail(dot)com> 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