Re: CheckAttributeType() forgot to recurse into multiranges - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: CheckAttributeType() forgot to recurse into multiranges
Date
Msg-id aenIp7idu8oFmNv6@paquier.xyz
Whole thread
In response to CheckAttributeType() forgot to recurse into multiranges  (Heikki Linnakangas <hlinnaka@iki.fi>)
List 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

Attachment

pgsql-hackers by date:

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