| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PL/pgSQL: fix validation of anycompatiblemultirange |
| Date: | 2026-10-26 16:58:55 |
| Message-ID: | CAFj8pRC3E1_19DuA5JnLtbievL3vB_jtT5FnxXWLHnOq8pd2bA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi
po 26. 10. 2026 v 14:06 odesílatel Jeevan Chalke <
jeevan(dot)chalke(at)enterprisedb(dot)com> napsal:
> Hi,
>
> When validating a PL/pgSQL function with polymorphic arguments or result
> type,
> we substitute a plausible concrete type for each polymorphic type. This is
> done in two places, cfunc_resolve_polymorphic_argtypes() in funccache.c
> for
> arguments and plpgsql_compile_callback() in pl_comp.c for the result type.
> Both handle anycompatiblerange and anymultirange, but neither handles
> anycompatiblemultirange. This appears to have been missed when
> multiranges
> were added in 6df7a9698bb (v14), which added the anymultirange case to
> both
> places but did not add any PL/pgSQL test for anycompatiblemultirange.
>
> This has two visible effects. First, with check_function_bodies = ON,
> creating
> a function with an anycompatiblemultirange argument fails:
>
> CREATE FUNCTION f1(x anycompatiblemultirange)
> RETURNS anycompatiblemultirange AS $$
> BEGIN RETURN x; END $$ LANGUAGE plpgsql;
> ERROR: PL/pgSQL functions cannot accept type anycompatiblemultirange
>
> The same function can be created with check_function_bodies = off, and
> then
> works, so only the validation path is wrong.
>
> Second, a function that only returns anycompatiblemultirange is compiled
> by
> the validator with an int4 result type. The function cache key does not
> include the result type, so a later call in the same session with the same
> argument types the validator used (int4range here) reuses that entry, and
> fails:
>
> CREATE FUNCTION f1(x anycompatiblerange)
> RETURNS anycompatiblemultirange AS $$
> BEGIN RETURN multirange(x); END $$ LANGUAGE plpgsql;
> SELECT f1(int4range(42, 49));
> ERROR: invalid input syntax for type integer: "{[42,49)}"
>
> A call with other argument types, say numrange, gets its own cache entry
> and
> works, which is why this can go unnoticed.
>
> The attached patch maps anycompatiblemultirange to int4multirange in both
> places, as is already done for anymultirange, which fixes both issues.
>
> It also adds two regression tests to plpgsql.sql, one for each case above.
> Both fail without the fix.
>
> Since this is a plain bug fix, I think it should be back-patched to v14,
> where
> anycompatiblemultirange was introduced, but I'd like to hear what others
> think. On branches before v18 the argument-type fix would go in pl_comp.c
> ,
> since cfunc_resolve_polymorphic_argtypes() in funccache.c is newer.
>
>
+1
Pavel
> Thanks
>
> --
> *Jeevan Chalke*
> *Senior Principal Engineer, Engineering Manager*
> *Product Development*
>
> enterprisedb.com <https://www.enterprisedb.com>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-10-26 16:59:24 | Re: Let's drop support for named POSIX semaphores |
| Previous Message | g l | 2026-10-26 16:47:26 | [RFC PATCH] Skip LATERAL check in join_clause_is_movable_to() during OR-clause restriction extraction |