Re: Extract numeric filed in JSONB more effectively

Andy Fan <zhihui.fan1213@gmail.com>

From: Andy Fan <zhihui.fan1213@gmail.com>
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>
Date: 2023-08-15T06:04:19Z
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

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add trailing commas to enum definitions