MIME-Version: 1.0
References: <CAKU4AWoqAVya6PBhn+BCbFaBMt3z-2=i5fKO3bW=6HPhbid2Dw@mail.gmail.com>
 <CACJufxHASOEpngQ8V2tbXgs4VZC3ETrVbS=uk0KC_B_J1j7ejQ@mail.gmail.com>
 <CAKU4AWrap1zpYqunJwWTN=CdP7E8e0U4mYmwn7hvTW3ERuENVg@mail.gmail.com>
 <CAFj8pRD-R-GsGCjeYApbhZoiW8TV6zACaYStMBMM0=--+WgN_A@mail.gmail.com>
 <CAKU4AWpDdFXAD+dMC1HeErXSKBUUBRGWkf=dAcX3wZgBNsWM=g@mail.gmail.com>
 <CAFj8pRAO3oEiBaJJ9=HZp6CoP2ffbwSgrKkLKjPfYZwx9wOOuQ@mail.gmail.com>
 <CAKU4AWoCHpKAVuQeOrk44cVPy_dVxn1aHrMUvHy5Ag-daFCSsQ@mail.gmail.com>
 <CAFj8pRD4cdUmK0RG4oN5B2KRSeDhwfMYaL=XpfEu4iaLeZ_Kow@mail.gmail.com>
 <CAKU4AWp8ab61e96v57OaB-Gm1bMfBNVLVy+s17U6_Ne3veB84g@mail.gmail.com>
 <3507485.1691090027@sss.pgh.pa.us> <CAKU4AWp+KLes8g=BWLqZfDmW9+=ZY0UC4G0i3qVcYEviK_dDTA@mail.gmail.com>
 <900892914fdc3f477b101d699efb40e0@anastigmatix.net> <903341.1692022214@sss.pgh.pa.us>
 <CAKU4AWrBY9GHj9oZbvhiOG1BgiWyZC8FGPAET-CfRKDhYyv1HQ@mail.gmail.com>
 <CAKU4AWrGM5bK7wi4Y8bTYhKgh=A1fW=X00eC_jfk6_JXyaEURQ@mail.gmail.com> <CAFj8pRC+4pvSuibB2xcNKJ=6PSF=TAcOtRNpdLPBXZjijFg7ag@mail.gmail.com>
In-Reply-To: <CAFj8pRC+4pvSuibB2xcNKJ=6PSF=TAcOtRNpdLPBXZjijFg7ag@mail.gmail.com>
From: Andy Fan <zhihui.fan1213@gmail.com>
Date: Tue, 15 Aug 2023 14:04:19 +0800
Message-ID: <CAKU4AWoVBY99ECX5C8XtrfaXCs2SonJjSGFOQrFUPxtRo4THPg@mail.gmail.com>
Subject: Re: Extract numeric filed in JSONB more effectively
To: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Chapman Flack <chap@anastigmatix.net>, 
	jian he <jian.universality@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000d1bfbe0602eff375"
Archived-At: <https://www.postgresql.org/message-id/CAKU4AWoVBY99ECX5C8XtrfaXCs2SonJjSGFOQrFUPxtRo4THPg%40mail.gmail.com>
Precedence: bulk

--000000000000d1bfbe0602eff375
Content-Type: text/plain; charset="UTF-8"

>
>
> My idea of an ideal solution is the introduction of the possibility to use
> "any" pseudotype as return type with possibility to set default return
> type. Now, "any" is allowed only for arguments. The planner can set the
> expected type when it knows it, or can use the default type.
>
> so for extraction of jsonb field we can use FUNCTION
> jsonb_extract_field(jsonb, text) RETURNS "any" DEFAULT jsonb
>

Is this an existing framework or do you want to create something new?

>
> if we call SELECT jsonb_extract_field(..., 'x') -> then it returns jsonb,
> if we use SELECT jsonb_extract_field('...', 'x')::date, then it returns date
>

If so, what is the difference from the current  jsonb->'f'   and
(jsonb->'f' )::date?

>
> With this possibility we don't need to touch to cast functions, and we can
> simply implement similar functions for other non atomic types.
>

What do you mean by "atomic type" here?   If you want to introduce some new
framework,  I think we need a very clear benefit.

-- 
Best Regards
Andy Fan

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div><br></d=
iv><div>My idea of an ideal solution is the introduction of the possibility=
 to use &quot;any&quot; pseudotype as return type with possibility to set d=
efault return type. Now, &quot;any&quot; is allowed only for arguments. The=
 planner can set the expected type when it knows it, or can use the default=
 type.</div><div><br></div><div>so for extraction of jsonb field we can use=
 FUNCTION jsonb_extract_field(jsonb, text) RETURNS &quot;any&quot; DEFAULT =
jsonb</div></div></div></blockquote><div><br></div><div>Is this an existing=
 framework or do you want to create something new?=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_q=
uote"><div><br></div><div>if we call SELECT jsonb_extract_field(..., &#39;x=
&#39;) -&gt; then it returns jsonb, if we use SELECT jsonb_extract_field(&#=
39;...&#39;, &#39;x&#39;)::date, then it returns date<br></div></div></div>=
</blockquote><div><br></div><div>If so, what is the difference from the cur=
rent=C2=A0 jsonb-&gt;&#39;f&#39;=C2=A0 =C2=A0and (jsonb-&gt;&#39;f&#39; )::=
date?=C2=A0=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div class=3D"gmail_quote"><div></div><div><br></div><div>Wi=
th this possibility we don&#39;t need to touch to cast functions, and we ca=
n simply implement similar functions for other non atomic types.<br></div><=
div></div></div></div></blockquote><div>=C2=A0</div><div>What do you mean b=
y &quot;atomic type&quot; here?=C2=A0 =C2=A0If you want to introduce some n=
ew framework,=C2=A0 I think we need a very clear benefit.=C2=A0=C2=A0</div>=
</div><div><br></div><span class=3D"gmail_signature_prefix">-- </span><br><=
div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr">Best Regards<div=
>Andy Fan</div></div></div></div>

--000000000000d1bfbe0602eff375--