From: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Chapman Flack <chap(at)anastigmatix(dot)net>, jian he <jian(dot)universality(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Extract numeric filed in JSONB more effectively |
Date: | 2023-08-15 06:04:19 |
Message-ID: | CAKU4AWoVBY99ECX5C8XtrfaXCs2SonJjSGFOQrFUPxtRo4THPg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2023-08-15 06:04:54 | Re: proposal: jsonb_populate_array |
Previous Message | Michael Meskes | 2023-08-15 05:59:42 | Re: ECPG Semantic Analysis |