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