> On Nov 11, 2026, at 02:09, Luca Cappelletti <[email protected]>
> 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/
