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

On Sun, Aug 16, 2020 at 5:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

> "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.)
>

I was making that assumption.

In the pseudo-code:

else if (pispreferred) continue; /* never move away from a preferred type */
{the rest of the else ifs from above}

In the docs:

5. If the first non-unknown type is a preferred type it is chosen,
otherwise it is made a candidate, and then,
6. each subsequent type is compared to the current candidate, with a new
candidate being chosen only when there exists a non-mutal implicit cast to
the new type.
6a. If at any point a preferred type is made a candidate then it will be
chosen.

David J.