On Tue, Apr 7, 2026 at 5:00 PM Andy Fan <[email protected]> wrote:
> Haibo Yan <[email protected]> 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
