Re: remaining sql/json patches

On Thu, Sep 21, 2023 at 4:14 AM 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> wrote:
> On Tue, Sep 19, 2023 at 7:37 PM jian he <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.

OK, thanks for confirming.

Here is a set where I've included the above change in 0003.

I had some doubts about the following bit in 0001 but I've come to
know through some googling that LLVM handles this alright:

+/*
+ * Emit constant oid.
+ */
+static inline LLVMValueRef
+l_oid_const(Oid i)
+{
+ return LLVMConstInt(LLVMInt32Type(), i, false);
+}
+

The doubt I had was whether the Oid that l_oid_const() takes, which is
an unsigned int, might overflow the integer that LLVM provides through
LLVMConstInt() here. Apparently, LLVM IR always uses the full 32-bit
width to store the integer value, so there's no worry of the overflow
if I'm understanding this correctly.

Patches 0001 and 0002 look ready to me to go in. Please let me know
if anyone thinks otherwise.

--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com