Re: Inaccurate description of UNION/CASE/etc type selection

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Sun, Aug 16, 2020 at 2:26 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Seems like 5 and 6 need to be merged - the chosen type is the first one
> that all subsequent types can be implicitly cast to.  We do not guarantee
> that previous types will be implicitly convertible to this type.
> In pseudo-code:
> else if (can_coerce(n->p)) continue /* matches when pispreferred */
> else if (can_coerce(p->n)) "change chosen type"
> else continue /* but now we expect a runtime implicit cast not found error
> */

This formulation fails to account for the pispreferred check, though.
The pseudo-code would be correct if you made the first line be

else if (pispreferred || can_coerce(n->p)) continue

but then it doesn't map neatly to a description that fails to mention
preferred-ness.  (Note that this would be simpler if we could assume
that pispreferred implies that there is a cast from every other category
member type to p.  But there are counterexamples.)