Re: [PATCH] Use the multirange schema for its array type name

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Luca Cappelletti <cappelletti(dot)luca94(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PATCH] Use the multirange schema for its array type name
Date: 2026-11-13 01:19:54
Message-ID: 2640ED70-1B8C-446F-9915-181ADA7D668D@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Nov 11, 2026, at 02:09, Luca Cappelletti <cappelletti(dot)luca94(at)gmail(dot)com> wrote:
>
> Creating a PostgreSQL range with `MULTIRANGE_TYPE_NAME` in another schema can fail with `type "_m" already exists` when that schema contains an explicit type named `_m`. `DefineRange` checks generated array names in the range's schema, although the array belongs in the multirange's schema. A name occupied only in the range's schema can also cause an unnecessary suffix.
>
> The attached patch uses the multirange's namespace for the name lookup.
>
> The defect is present in the inspected `REL_14_0`, `REL_18_STABLE`, and `master` sources. Please consider backpatching to affected supported releases.
>
> Best,
> Luca
>
> GitHub: https://github.com/LucaCappelletti94
> <multirange_patch.patch>

Looking at the code in DefineRange():
```
/* Create the multirange's array type */

multirangeArrayName = makeArrayTypeName(multirangeTypeName, typeNamespace);

TypeCreate(multirangeArrayOid, /* force assignment of this type OID */
multirangeArrayName, /* type name */
multirangeNamespace, /* namespace */
….
```

The collision check in makeArrayTypeName() is performed against typeNamespace, but the array type is actually created in multirangeNamespace. This looks like an oversight in the original commit 6df7a96.

The patch simply replaces typeNamespace with multirangeNamespace, which looks correct to me.

I think it might also be worth backpatching to all supported branches, down to 14 or 15? it seems now is approaching 14’s end of life.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-11-13 02:05:08 Re: Bug report and fix for: COMMIT/ROLLBACK AND CHAIN after an error drops the isolation level
Previous Message Richard Guo 2026-11-13 01:13:40 Re: Wrong results from GROUP BY column removal