TYPCATEGORY_{NETWORK,USER} [was Dubious usage of TYPCATEGORY_STRING]

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