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