Re: Extract numeric filed in JSONB more effectively

On Mon, Aug 14, 2023 at 10:10 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> > Providing a function with return type declared internal but
> > with no parameter of that type is not good,
>
> Not so much "not good" as "absolutely, positively WILL NOT HAPPEN".

Chap is pretty nice to others:).

>
>
> because then a
> > user could, in principle, call it and obtain a value of
> > 'internal' type, and so get around the typing rules that
> > prevent calling other internal functions.
>
> Right --- it'd completely break the system's type-safety for
> other internal-using functions.
>
>
I do see something bad in opr_sanity.sql. Pavel suggested
get_fn_expr_argtype which can resolve this issue pretty well, so
I have changed

jsonb_extract_xx_type(.., Oid taget_oid) -> anyelement.
to
jsonb_extract_xx_type(.., anyelement) -> anyelement.

The only bad smell left is since I want to define jsonb_extract_xx_type
as strict so I can't use jsonb_extract_xx_type(.., NULL::a-type)
since it will be evaluated to NULL directly. So I hacked it with

/* mock the type. */
Const *target = makeNullConst(fexpr->funcresulttype,
-1,
InvalidOid);

/* hack the NULL attribute */
/*

* Since all the above functions are strict, we can't input

* a NULL value.

*/
target->constisnull = false;

jsonb_extract_xx_type just cares about the argtype, but
'explain select xx' will still access the const->constvalue.
const->constvalue is 0 which is set by makeNullConst currently,
and it is ok for the current supported type. but I'm not sure
about the future or if we still have a better solution.

v6 is attached. any feedback is welcome!

--
Best Regards
Andy Fan