transformJsonFuncExpr pathspec cache lookup failed - Mailing list pgsql-hackers

From jian he
Subject transformJsonFuncExpr pathspec cache lookup failed
Date
Msg-id CACJufxHunVg81JMuNo8Yvv_hJD0DicgaVN2Wteu8aJbVJPBjZA@mail.gmail.com
Whole thread Raw
List pgsql-hackers
hi.

in transformJsonFuncExpr:

    path_spec = transformExprRecurse(pstate, func->pathspec);
    path_spec = coerce_to_target_type(pstate, path_spec, exprType(path_spec),
                                      JSONPATHOID, -1,
                                      COERCION_EXPLICIT, COERCE_IMPLICIT_CAST,
                                      exprLocation(path_spec));
    if (path_spec == NULL)
        ereport(ERROR,
                (errcode(ERRCODE_DATATYPE_MISMATCH),
                 errmsg("JSON path expression must be of type %s, not
of type %s",
                        "jsonpath", format_type_be(exprType(path_spec))),
                 parser_errposition(pstate, exprLocation(path_spec))));

There is no test for this, if you try it, you can easily reach "cache
lookup failed".
SELECT JSON_VALUE(jsonb 'null', NULL::date);
ERROR:  cache lookup failed for type 0

because we first call ``format_type_be(exprType(path_spec))),`` then ereport.
format_type_be can not code with InvalidOid.

A patch is attached.
-----------
Also, note that we allow:
SELECT * FROM JSON_TABLE(jsonb'"1.23"', '$' COLUMNS (js2 int PATH '$'));
but don't allow
SELECT * FROM JSON_TABLE(jsonb'"1.23"', '$'::jsonpath COLUMNS (js2 int
PATH '$'));

Maybe we should support this.
since every A_Const should have a type for it. Allowing something like:
JSON_TABLE(jsonb '"1.23"', '$'::some_jsonpath_type ... )
seems consistent.
I guess that's a separate issue, so I didn't touch it.

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

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [PATCH] Fix orphaned backend processes on Windows using Job Objects
Next
From: Thomas Munro
Date:
Subject: Re: [Patch] Windows relation extension failure at 2GB and 4GB