Re: remaining sql/json patches

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 <andrew(at)dunslane(dot)net> wrote:

>
> On 2023-09-19 Tu 23:07, Amit Langote wrote:
>
> On Tue, Sep 19, 2023 at 9:00 PM Amit Langote <amitlangote09(at)gmail(dot)com> <amitlangote09(at)gmail(dot)com> wrote:
>
> On Tue, Sep 19, 2023 at 7:37 PM jian he <jian(dot)universality(at)gmail(dot)com> <jian(dot)universality(at)gmail(dot)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/