Hi! We'd like to help to implement SQL/JSON in v18 and have adapted the JSON_TABLE PLAN clause code from patch v45-0001-JSON_TABLE.patch.
Could you please review it? There are some places with questionable behavior - please check the JSON_TABLE plan execution section in tests, and I'm not sure about the correctness of some tests. On Wed, Sep 20, 2023 at 10:15 PM Andrew Dunstan <and...@dunslane.net> wrote: > > On 2023-09-19 Tu 23:07, Amit Langote wrote: > > On Tue, Sep 19, 2023 at 9:00 PM Amit Langote <amitlangot...@gmail.com> > <amitlangot...@gmail.com> wrote: > > On Tue, Sep 19, 2023 at 7:37 PM jian he <jian.universal...@gmail.com> > <jian.universal...@gmail.com> wrote: > > > -------------------https://www.postgresql.org/docs/current/extend-type-system.html#EXTEND-TYPES-POLYMORPHIC > > When the return value of a function is declared as a polymorphic type, there > must be at least one argument position that is also > polymorphic, and the actual data type(s) supplied for the polymorphic > arguments determine the actual result type for that call. > > select json_query(jsonb'{"a":[{"a":[2,3]},{"a":[4,5]}]}','$.a[*].a?(@<=3)' > returning anyrange); > should fail. Now it returns NULL. Maybe we can validate it in > transformJsonFuncExpr? > ------------------- > > I'm not sure whether we should make the parser complain about the > weird types being specified in RETURNING. > > Sleeping over this, maybe adding the following to > transformJsonOutput() does make sense? > > + if (get_typtype(ret->typid) == TYPTYPE_PSEUDO) > + ereport(ERROR, > + errcode(ERRCODE_FEATURE_NOT_SUPPORTED), > + errmsg("returning pseudo-types is not supported in > SQL/JSON functions")); > + > > > > Seems reasonable. > > > cheers > > > andrew > > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com > > -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/
v17-0006-JSON-TABLE-PLAN-clause.patch
Description: Binary data
