PL/pgSQL: fix validation of anycompatiblemultirange

From: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: PL/pgSQL: fix validation of anycompatiblemultirange
Date: 2026-10-26 13:05:52
Message-ID: CAM2+6=VEXCo7tPaxX+9_zN8SJ9DiPp2NTj_sPGN+Tb0wWTBp=w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Thanks

--
*Jeevan Chalke*
*Senior Principal Engineer, Engineering Manager*
*Product Development*

enterprisedb.com <https://www.enterprisedb.com>

Attachment Content-Type Size
v1-0001-Fix-PL-pgSQL-validation-of-anycompatiblemultirang.patch application/octet-stream 5.0 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Aidar Imamov 2026-10-26 13:21:47 Fix recovery conflict canceling the startup progress timeout
Previous Message Henson Choi 2026-10-26 12:54:06 Re: [PATCH v1] Fix for bug #19773 : pg_dump differing generation expressions of inherited columns