Re: CheckAttributeType() forgot to recurse into multiranges

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CheckAttributeType() forgot to recurse into multiranges
Date: 2026-04-23 07:22:15
Message-ID: aenIp7idu8oFmNv6@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 22, 2026 at 11:56:12PM +0300, Heikki Linnakangas wrote:
> That looks like a straightforward oversight in CheckAttributeType(). When
> multiranges were introduced, it didn't get the memo.

Nice catch.

--- this must be rejected to avoid self-inclusion issues:
+-- these must be rejected to avoid self-inclusion issues:
alter type two_ints add attribute c two_ints_range;
ERROR: composite type two_ints cannot be made a member of itself
+alter type two_ints add attribute c two_ints_multirange;
+ERROR: composite type two_ints cannot be made a member of itself

If you want to create a parallel with multirangetypes.sql, this
choking case may be better if placed there rather than rangetypes.sql,
as it is a multi case. Not a big deal, still.

> While working on the fix, I noticed that in case of dropped columns,
> CheckAttributeType() is called with InvalidOid. It tolerates that, but it
> seems accidental and it performs a bunch of futile syscache lookups with
> InvalidOid, so it would be better to not do that. The second patch fixes
> that.

This one seems harmless as far as I can see, but we should be careful
to bypass any attisdropped while scanning a set of attributes, so a
backpatch is in order, indeed. LGTM.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2026-04-23 07:24:49 Re: Redundant/mis-use of _(x) gettext macro?
Previous Message shveta malik 2026-04-23 07:07:41 Re: Warn on missing replica identity in CREATE/ALTER PUBLICATION