Re: Extract numeric filed in JSONB more effectively

Hi Chapman,

Thanks for the review!

The idea of an 'internal' return type with no 'internal' parameter
> was quickly and rightly shot down.

Yes, it mainly breaks the type-safety system. Parser need to know
the result type, so PG defines the rule like this:

anyelement fn(anyment in);

if the exprType(in) in the query tree is X, then PG would think fn
return type X. that's why we have to have an anyelement in the
input.

> But it would have seemed to me
> enough to address that objection by using 'internal' also in its
> parameter list. I could imagine a function declared with two
> 'internal' parameters, one understood to be a JsonbValue and one
> understood to be a type oid, and an 'internal' result, treated in
> the rewritten expression tree as binary-coercible to the desired
> result.
>

I have some trouble understanding this. are you saying something
like:

internal fn(internal jsonValue, internal typeOid)?

If so, would it break the type-safety system? And I'm not pretty
sure the 'binary-coercible' here. is it same as the 'binary-coercible'
in "timestamp is not binary coercible with timestamptz since..."?
I have a strong feeling that I think I misunderstood you here.

> Perhaps there are parts of that rewriting that no existing node type
> can represent?
>

I didn't understand this as well:(:(

But I have the sense that that approach was abandoned early, in
> favor of the current approach using user-visible polymorphic
> types, and supplying typed dummy constants for use in the
> resolution of those types, with a new function introduced to create
> said dummy constants, including allocation and input conversion
> in the case of numeric, just so said dummy constants can be
> passed into functions that have no use for them other than to
> call get_fn_expr_argtype to recover the type oid, which was the
> only thing needed in the first place.

Yes, but if we follow the type-safety system, we can't simply input
a Oid targetOid, then there are some more considerations here:
a). we can't use the makeNullConst because jsonb_xxx_type is
strict, so if we have NULL constant input here, the PG system
will return NULL directly. b). Not only the type oid is the thing
We are interested in the const.constvalue is as well since
'explain select xxxx' to access it to show it as a string.
Datum(0) as the constvalue will crash in this sense. That's why
makeDummyConst was introduced.

> something like "assertion of
> 'internal'-to-foo binary coercibility, vouched by a prosupport
> function", would that be a bad thing?
>

I can't follow this as well. Could you provide the function prototype
here?

--
Best Regards
Andy Fan