On Mon, Aug 14, 2023 at 10:10 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> Chapman Flack <c...@anastigmatix.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
v6-0001-optimize-casting-jsonb-to-a-given-type.patch
Description: Binary data
