Hi jian: On Thu, Aug 17, 2023 at 12:32 AM jian he <jian.universal...@gmail.com> wrote:
> On Wed, Aug 16, 2023 at 2:28 PM Andy Fan <zhihui.fan1...@gmail.com> wrote: > > > > update with the correct patch.. > > regression=# select proname, pg_catalog.pg_get_function_arguments(oid) > from pg_proc > where proname = 'jsonb_extract_path_type'; > proname | pg_get_function_arguments > > -------------------------+-------------------------------------------------------------------- > jsonb_extract_path_type | from_json jsonb, VARIADIC path_elems > text[], target_oid anyelement > (1 row) > > VARIADIC should be the last argument? > Currently if users call this function directly(usually I don't think so), they will get something wrong. This issue is fixed in the v9 version. To keep the consistency among all the functions, I moved the 'target_type anyelement' to the 1st argument. Thanks for the report! > select jsonb_array_element_type(jsonb'[1231]',0, null::int); > now return null. > Should it return 1231? > No, this is by design. the function is declared as strict, so any NULL inputs yield a NULL output. That's just what we talked above (the markDummyConst section). I don't think this should be addressed. > select jsonb_array_element_type(jsonb'[1231]',0, '1'::jsonb); > will crash > OK, looks I didn't pay enough attention to the 'user directly call jsonb_xx_type' function, so I changed the code in v9 based on your suggestion. Thanks for the review, v9 attached! -- Best Regards Andy Fan
test.sql
Description: Binary data
v9-0001-optimize-casting-jsonb-to-a-given-type.patch
Description: Binary data
