MIME-Version: 1.0
References: <87r0hmvuvr.fsf@163.com>
 <8102ff5b-b156-409e-a48f-e53e63a39b36@eisentraut.org>
 <8734t6c5rh.fsf@163.com> <87o7bn7z56.fsf@163.com> <875xx197bp.fsf@163.com>
 <87ttk0lgcx.fsf@163.com>
 <CAApHDvqnUONCN54dAXdH678ELK7aH2gyVhh0GjTRtrexPd9YMw@mail.gmail.com>
 <8734m5fua1.fsf@163.com>
 <mmilfltxeqgajpi4zok2v2moudot6bhdmwsqgjgnymz3nvkvng@k3caignaldcp>
 <87a5dx4cfb.fsf@163.com>
 <cudr6wao4hz2otlycx2z2equkigbjxslxvzqb3ejfc4amroheo@frqbvffcgqnu>
 <7487A577-7BDC-4B94-9FFA-741E95439BFC@gmail.com> <873417fgc0.fsf@163.com>
 <CABXr29GhnWxrGXD2YijYSDxwObGLqOsf8gvfzrFu=UcYU71XYA@mail.gmail.com>
 <87eckqz5i9.fsf@163.com>
In-Reply-To: <87eckqz5i9.fsf@163.com>
From: Haibo Yan <tristan.yim@gmail.com>
Date: Tue, 7 Apr 2026 18:21:45 -0700
Message-ID: 
 <CABXr29HN04CqHBGZ_k6_jQmCL5FO59tDE4PUL9U56Rpu=d4=0A@mail.gmail.com>
Subject: Re: Extract numeric filed in JSONB more effectively
To: Andy Fan <zhihuifan1213@163.com>
Cc: Dmitry Dolgov <9erthalion6@gmail.com>,
 David Rowley <dgrowleyml@gmail.com>,
	Peter Eisentraut <peter@eisentraut.org>,
 Amit Langote <amitlangote09@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
 jian he <jian.universality@gmail.com>,
	Chapman Flack <chap@anastigmatix.net>, pgsql-hackers@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000c88b2e064ee8b9f7"
Archived-At: 
 <https://www.postgresql.org/message-id/CABXr29HN04CqHBGZ_k6_jQmCL5FO59tDE4PUL9U56Rpu%3Dd4%3D0A%40mail.gmail.com>
Precedence: bulk

--000000000000c88b2e064ee8b9f7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 7, 2026 at 5:00=E2=80=AFPM Andy Fan <zhihuifan1213@163.com> wro=
te:

> Haibo Yan <tristan.yim@gmail.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

--000000000000c88b2e064ee8b9f7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Apr 7, 2026 at 5:00=E2=80=AFPM An=
dy Fan &lt;<a href=3D"mailto:zhihuifan1213@163.com">zhihuifan1213@163.com</=
a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">Haibo Yan &lt;<a href=3D"mailto:=
tristan.yim@gmail.com" target=3D"_blank">tristan.yim@gmail.com</a>&gt; writ=
es:<br>
<br>
Hi Haibo,<br>
<br>
&gt; I agree that if this approach is extended to the full matrix naively,<=
br>
&gt; duplication will become a real issue.<br>
<br>
Could you summary how it would be? I think it would be helpful for<br>
others to review.=C2=A0 Otherwise every reviewer needs to count them many<b=
r>
times. <br>
<br>
-- <br>
Best Regards<br>
Andy Fan<br></blockquote>Hi Andy,<br>Sure. <br>


<p class=3D"gmail-p1">My current thought is to extend it in stages, rather =
than trying to solve the full matrix in a single patch.</p>
<p class=3D"gmail-p2">A rough plan would be:</p>
<p class=3D"gmail-p3"><span class=3D"gmail-s1"></span></p>1. Keep the curre=
nt stage-1 patch small and validate the basic approach first<p class=3D"gma=
il-p3"><span class=3D"gmail-s1"></span></p><ul><li>
<p class=3D"gmail-p1"><span class=3D"gmail-s1">jsonb_object_field</span> / =
<span class=3D"gmail-s1">-&gt;</span> / equivalent subscripting form</p>
</li><li>
<p class=3D"gmail-p1">casts to <span class=3D"gmail-s1">numeric</span> and =
<span class=3D"gmail-s1">bool</span></p>
</li><li>
<p class=3D"gmail-p1">support-function rewrite directly to explicit typed e=
xtractor functions</p></li></ul>2. Extend target types before extending ext=
ractor families<p class=3D"gmail-p3"><span class=3D"gmail-s1"></span></p><u=
l><li>
<p class=3D"gmail-p1">add <span class=3D"gmail-s1">int4</span> / <span clas=
s=3D"gmail-s1">int8</span> / <span class=3D"gmail-s1">float8</span> for the=
 same object-field family first</p>
</li><li>
<p class=3D"gmail-p1">keep the SQL-visible rewrite targets explicit, e.g.</=
p>
<p class=3D"gmail-p2"><span class=3D"gmail-s1"></span></p><ul><li>
<p class=3D"gmail-p1">jsonb_object_field_int4</p>
</li><li>
<p class=3D"gmail-p1">jsonb_object_field_int8</p>
</li><li>
<p class=3D"gmail-p1">jsonb_object_field_float8</p>
</li></ul><p></p>
</li><li>
<p class=3D"gmail-p1">avoid the previous numeric-intermediate rewrite shape=
</p></li></ul>3. Then extend to other extractor families with the same over=
all pattern<p class=3D"gmail-p3"><span class=3D"gmail-s1"></span></p><ul><l=
i>
<p class=3D"gmail-p1"><span class=3D"gmail-s1">likely starting with </span>=
jsonb_array_element<span class=3D"gmail-s1"> and </span>jsonb_extract_path<=
/p>
</li><li>
<p class=3D"gmail-p1"><span class=3D"gmail-s1">and possibly </span>jsonb_pa=
th_query_first<span class=3D"gmail-s1"> later</span></p>
</li><li>
<p class=3D"gmail-p1">each family would still rewrite to explicit typed ext=
ractor entry points, e.g.</p>
<p class=3D"gmail-p2"><span class=3D"gmail-s1"></span></p><ul><li>
<p class=3D"gmail-p1">jsonb_array_element_numeric</p>
</li><li>
<p class=3D"gmail-p1">jsonb_extract_path_bool</p>
</li><li>
<p class=3D"gmail-p1">jsonb_path_query_first_int4</p>
</li></ul><p></p>
</li></ul><p></p>4. Keep duplication manageable by sharing the implementati=
on underneath<p class=3D"gmail-p3"><span class=3D"gmail-s1"></span></p><ul>=
<li>
<p class=3D"gmail-p1">keep the SQL/catalog-level rewrite targets explicit f=
or readability and reviewability</p>
</li><li>
<p class=3D"gmail-p1">but factor the C implementation into:</p>
<p class=3D"gmail-p2"><span class=3D"gmail-s1"></span></p><ul><li>
<p class=3D"gmail-p1">extractor-family lookup helpers</p>
</li><li>
<p class=3D"gmail-p1">target-type conversion helpers</p>
</li><li>
<p class=3D"gmail-p1">thin wrappers, possibly generated with small macros</=
p></li></ul></li></ul>
<p class=3D"gmail-p1">So the idea would be: explicit rewrite targets at the=
 SQL/catalog level, but shared lookup/conversion code underneath, instead o=
f going back to the earlier start/finish/internal pipeline.</p>
<p class=3D"gmail-p1">I agree that if this is extended naively across the f=
ull matrix, duplication will become a real issue. My reason for keeping the=
 current patch narrow is that I wanted to first validate this simpler rewri=
te shape on a small subset before deciding how best to scale it further.</p=
>
<p class=3D"gmail-p1">Regards,</p>
<p class=3D"gmail-p1">Haibo</p><br>


</div></div>

--000000000000c88b2e064ee8b9f7--