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

On 01/03/22 13:55, Tom Lane wrote:
> I do see an argument against reclassifying macaddr[8] into
> TYPCATEGORY_NETWORK now: we generally expect that if a
> category has a preferred type, any member type of the category
> can be cast to that preferred type.

I was wondering about the details of how that information gets used.
It seems partly redundant with what you learn from pg_cast. The
CREATE TYPE documentation says:

The category and preferred parameters can be used to help control
which implicit cast will be applied in ambiguous situations. ...
For types that have no implicit casts to or from any other types,
it is sufficient to leave these settings at the defaults. However,
for a group of related types that have implicit casts, it is often
helpful ...

which would suggest (to me on a first reading, anyway) that one starts
in pg_cast to find out what implicit casts, if any, exist, and then
looks to category and preferred if needed to resolve any ambiguity
that remains.

If understood that way, it doesn't seem to imply any ill effect of
having types within a category that might be partitioned into a few
disjoint subsets by "implicit cast exists between". (Such subsets
might be regarded as autodiscovered mini-categories.) But I could be
off-base to understand it that way.

Are there spots in the code where the expectation "if a category has
a preferred type, any member type of the category can be cast to that
preferred type" really takes that stronger form?

Hmm, I guess I can see some spots in Chapter 10, in the rules for
finding best-match operators or functions, or resolving UNION/CASE
types.

The UNION/CASE rules look like the effect might be benign: you have
step 4, inputs not of the same category => fail, then step 5, where
discovery of a preferred type can foreclose consideration of other
inputs, then step 6, implicit cast doesn't exist => fail. At first
blush, maybe that only fails the same cases that (if you treated
implicit-cast-related subsets within a category as mini-categories)
you would have failed in step 4.

The operator and function resolution rules seem harder to reason about,
and yeah, I haven't convinced myself their "any candidate accepts a
preferred type => discard candidates accepting non-preferred types" rules
couldn't end up discarding the part of the solution space where the
solution is, if disjoint "mini-categories" exist.

Regards,
-Chap