Hello David,
Thanks for checking this!
> There's a lot of complexity in the v18 patch that I don't understand
> the need for.
>
> I imagined you'd the patch should create a SupportRequestSimplify
> support function for jsonb_numeric() that checks if the input
> expression is an OpExpr with funcid of jsonb_object_field(). All you
> do then is ditch the cast and change the OpExpr to call a new function
> named jsonb_object_field_numeric() which returns the val.numeric
> directly. Likely the same support function could handle jsonb casts
> to other types too, in which case you'd just call some other function,
> e.g jsonb_object_field_timestamp() or jsonb_object_field_boolean().
Basically yes. The reason complexity comes when we many operators we
want to optimize AND my patch I want to reduce the number of function
created.
The optimized functions and operators includes:
1. jsonb_object_field / ->
2. jsonb_array_element / ->
3. jsonb_extract_path / #>
4. jsonb_path_query
5. jsonb_path_query_first
> ..., in which case you'd just call some other function,
> e.g jsonb_object_field_timestamp() or jsonb_object_field_boolean().
This works, but We need to create 2 functions for each operator. In the
patched case, we have 5 operators, so we need to create 10 functions.
op[1,2,3,4,5]_bool
op[1,2,3,4,5]_numeric.
Within the start / finish function, we need to create *7* functions.
op[1,2,3,4,5]_start : return the "JsonbVaue".
jsonb_finish_numeric: convert jsonbvalue to numeric
jsonb_finish_bool : convert jsonbvalue to bool.
I think the above is the major factor for the additional complexity.
Some other factors contribute to complexity a bit.
1. we also have jsonb_int{2,4,8}/float{4,8} in pg_proc for '->'
operator, not only numeric.
2. user may use OpExpr, like (jb->'x')::numeric, user may also use
FuncExpr, like (jsonb_object_field(a, 'x'))::numeric.
--
Best Regards
Andy Fan
