Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n4SCh-0001i8-47 for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Jan 2022 18:37:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n4SCf-000162-VX for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Jan 2022 18:37:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n4SCf-00015t-BI for pgsql-hackers@lists.postgresql.org; Mon, 03 Jan 2022 18:37:05 +0000 Received: from anastigmatix.net ([68.171.219.55]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n4SCb-0005yW-Eh for pgsql-hackers@lists.postgresql.org; Mon, 03 Jan 2022 18:37:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=anastigmatix.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Fy9UndFMqvf69IcsqhQYgZ90b+jBLOpeanahw2/Dgw8=; b=oW1H9R7o2ClTZ6Ti+Dwn3QqA90 I80USTlU1quE5mgnxST2+0dN31D6eheS7HrnmzW7JoEU1YIsH5Rrsb2BVzrDUMTZ2Cb8FkH+n5Zdk ZEjh4f7XlbYyxsmeF/RsMirG9fA3SfX/+QWcLJKiMQlxBjgwdugyAwL/sUlhb7LuWv0m6/JajmCrD 8UY+6aoFfgvuwAVOoGoIa38fQ5H1Kz5QnbVpuptAEPLLKm/OqI9atyCFwVJ0cdsiInDoseSqawnEx LqLoHobRaCYoHLFbCX0+8eYd8WUpZpCtcFLUXYW53uO/g4E9QpRTTPtvw0wdXPZAPMrc95txUz/N3 Fx+OgzMw==; Received: from 50-102-16-206.prtg.in.frontiernet.net ([50.102.16.206]:36893) by bay.acenet.us with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1n4SCZ-00HE6D-JT; Mon, 03 Jan 2022 13:37:00 -0500 Subject: TYPCATEGORY_{NETWORK,USER} [was Dubious usage of TYPCATEGORY_STRING] To: Tom Lane , pgsql-hackers@lists.postgresql.org References: <2216388.1638480141@sss.pgh.pa.us> From: Chapman Flack X-Enigmail-Draft-Status: N1110 Message-ID: <61D34244.4010606@anastigmatix.net> Date: Mon, 3 Jan 2022 13:36:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <2216388.1638480141@sss.pgh.pa.us> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bay.acenet.us X-AntiAbuse: Original Domain - lists.postgresql.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - anastigmatix.net X-Get-Message-Sender-Via: bay.acenet.us: authenticated_id: chap@anastigmatix.net X-Authenticated-Sender: bay.acenet.us: chap@anastigmatix.net X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 12/02/21 16:22, Tom Lane wrote: > taking the special types out of the string category, so 0002 > attached invents a separate TYPCATEGORY_INTERNAL category to > put them in. On the same general topic, was there a deliberate choice to put inet and cidr in TYPCATEGORY_NETWORK but macaddr and macaddr8 in TYPCATEGORY_USER? It looks like macaddr was put in category U (macaddr8 didn't exist yet) in bac3e83, the same commit that put inet and cidr into category I, apparently in order to "hew exactly to the behavior of the previous hardwired logic", on the principle that "any adjustment of the standard set of categories should be done separately". The birth of macaddr looks to have been back in 1998 in 2d69fd9, the same commit that added 'ipaddr'. Neither was added at that time to the hardcoded switch in TypeCategory(). The plot thickens.... ipaddr became inet in 8849655 (8 Oct 1998). cidr was added in 858a3b5 (21 Oct 1998). Then ca2995 added NETWORK_TYPE to TypeCategory and put inet and cidr in it (22 Oct 1998). Looks like that was done to reduce duplication of pg_proc entries between inet and cidr by allowing implicit coercion. And I guess you wouldn't want to suggest the existence of coercions between MAC addresses and inet addresses. But there aren't any such casts present in pg_cast anyway, so is that a persuasive present-day rationale for the (otherwise odd-seeming) split of these types across categories? They are grouped in a single documentation "category". Regards, -Chap