Re: PL/pgSQL: fix validation of anycompatiblemultirange

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>
>

In response to

Browse pgsql-hackers by date

  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