| 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
| 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 |