Re: Extract numeric filed in JSONB more effectively

On Tue, Apr 7, 2026 at 5:00 PM Andy Fan <zhihuifan1213(at)163(dot)com> wrote:

> Haibo Yan <tristan(dot)yim(at)gmail(dot)com> writes:
>
> Hi Haibo,
>
> > I agree that if this approach is extended to the full matrix naively,
> > duplication will become a real issue.
>
> Could you summary how it would be? I think it would be helpful for
> others to review. Otherwise every reviewer needs to count them many
> times.
>
> --
> Best Regards
> Andy Fan
>
Hi Andy,
Sure.

My current thought is to extend it in stages, rather than trying to solve
the full matrix in a single patch.

A rough plan would be:

1. Keep the current stage-1 patch small and validate the basic approach
first

-

jsonb_object_field / -> / equivalent subscripting form
-

casts to numeric and bool
-

support-function rewrite directly to explicit typed extractor functions

2. Extend target types before extending extractor families

-

add int4 / int8 / float8 for the same object-field family first
-

keep the SQL-visible rewrite targets explicit, e.g.

-

jsonb_object_field_int4
-

jsonb_object_field_int8
-

jsonb_object_field_float8

-

avoid the previous numeric-intermediate rewrite shape

3. Then extend to other extractor families with the same overall pattern

-

likely starting with jsonb_array_element and jsonb_extract_path
-

and possibly jsonb_path_query_first later
-

each family would still rewrite to explicit typed extractor entry
points, e.g.

-

jsonb_array_element_numeric
-

jsonb_extract_path_bool
-

jsonb_path_query_first_int4

4. Keep duplication manageable by sharing the implementation underneath

-

keep the SQL/catalog-level rewrite targets explicit for readability and
reviewability
-

but factor the C implementation into:

-

extractor-family lookup helpers
-

target-type conversion helpers
-

thin wrappers, possibly generated with small macros

So the idea would be: explicit rewrite targets at the SQL/catalog level,
but shared lookup/conversion code underneath, instead of going back to the
earlier start/finish/internal pipeline.

I agree that if this is extended naively across the full matrix,
duplication will become a real issue. My reason for keeping the current
patch narrow is that I wanted to first validate this simpler rewrite shape
on a small subset before deciding how best to scale it further.

Regards,

Haibo