Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wFz6v-005lfo-0t for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Apr 2026 18:49:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wFz6u-002xUb-1F for pgsql-hackers@arkaria.postgresql.org; Thu, 23 Apr 2026 18:49:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wFz6t-002xUK-35 for pgsql-hackers@lists.postgresql.org; Thu, 23 Apr 2026 18:49:12 +0000 Received: from meesny.iki.fi ([195.140.195.201]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wFz6r-00000002hX3-3lw5 for pgsql-hackers@postgresql.org; Thu, 23 Apr 2026 18:49:11 +0000 Received: from [10.0.2.15] (unknown [137.83.235.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by meesny.iki.fi (Postfix) with ESMTPSA id 4g1lVr0ZGtzyQm; Thu, 23 Apr 2026 21:49:07 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1776970148; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FpMj5ZtKzMfwDJz2hhAeMdPqjaZAQ3LIniAMZO629TA=; b=reAa0H4tWpPwYNLqPEn3tX3Zf8X2rPjtqjx4KHriQuJJQG0KrIyy7GLdcrczjHpm0oS63N q0why1IsxBNLh249UbRC/TsvjIF2JFvKv7xCzgnXvfHWZrFF5xf3DrhpnhDHam0XVJxNE7 sU9yHHuDAwaaluLymz5jmtSU14aXxgg= ARC-Seal: i=1; a=rsa-sha256; d=iki.fi; s=meesny; cv=none; t=1776970148; b=QfhyoEDjiYRQpWDQ04D+lVt4sLffkPtmMcVJvB9cCZVYnXv5baW8W8Pki5l7guTmm2fpLM 05Tg3sa0hKRK0GtNQm1AZTI8mElJAHZsNnE/tlpdtKpM6B7RTGacEqGDU+bYWcG819gkHa X0ahYbpq7d3rBelIGzTAjnmk7G1A86E= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1776970148; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FpMj5ZtKzMfwDJz2hhAeMdPqjaZAQ3LIniAMZO629TA=; b=TfKgwyutnYUrRrdSaWXlMbo4b96mKHY1Y+Mwa8eVIB8qsUo1W6o20Zo747wpa3dPwEmPlZ Uuj6/g+vKrH0YKiLZxQfBhdDj3QcJw6zps9hzDrfuQPDjIq91FywAIVt1zY9vYoni6z3K/ IBdmTUx8mw/WU1DCKU7EudmQd+lCzCY= Message-ID: Date: Thu, 23 Apr 2026 21:49:04 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: CheckAttributeType() forgot to recurse into multiranges To: Chao Li Cc: "pgsql-hackers@postgresql.org" References: <93ce56cd-02a6-4db1-8224-c8999372facc@iki.fi> <0B5FC478-013D-45D1-876A-AD3FE0C21E7C@gmail.com> Content-Language: en-US From: Heikki Linnakangas In-Reply-To: <0B5FC478-013D-45D1-876A-AD3FE0C21E7C@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 23/04/2026 06:24, Chao Li wrote: > I traced this patch set, 0002 looks good, but I have a suspicion about 0001. > > ``` > + else if (att_typtype == TYPTYPE_MULTIRANGE) > + { > + /* > + * If it's a multirange, recurse to check its plain range type. > + */ > + CheckAttributeType(attname, get_multirange_range(atttypid), > + get_range_collation(atttypid), > + containing_rowtypes, > + flags); > + } > ``` > > Looking at get_range_collation(), it only searches for RANGETYPE, so get_range_collation(atttypid) here will always return InvalidOid. This does not seem to cause a problem, because CheckAttributeType() will recurse into the TYPTYPE_RANGE path, and the collation will be evaluated there. > > But to make the logic clearer, I think we could just pass InvalidOid as the collation OID in the TYPTYPE_MULTIRANGE case. If we really want to pass the actual collation OID here, I think it would need to be done more like this: > > ``` > else if (att_typtype == TYPTYPE_MULTIRANGE) > { > Oid multirange_range_typid = get_multirange_range(atttypid); > Oid collation = get_range_collation(multirange_range_typid); > /* > * If it's a multirange, recurse to check its plain range type. > */ > CheckAttributeType(attname, multirange_range_typid, > collation, > containing_rowtypes, > flags); > } > ``` Oh, good catch, this is subtle. I'll change it to InvalidOid. As long as range types are not collatable, that'll do the right thing. If range types were collatable, I'm not sure what the right thing would be. It depends on what exactly the collation of a range type would mean. So, pushed with InvalidOid. Thanks for the review! - Heikki