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

On Mon, Aug 17, 2020 at 8:31 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> > More concisely:
>
> > Make the first input type a candidate type. Each subsequent input 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. If at any
> > point a preferred type is made a candidate then it will be chosen.
>
> So this is just a verbatim statement of the algorithm, which is what
> I was hoping to avoid :-(. But maybe there's no simpler way.
>
>
I got nothin'. The locking onto the preferred type is conditional on one
being chosen and there doesn't seem to be any greater principle that
emerges from the pairwise matching algorithm - at least given that implicit
casts are essentially randomly distributed and the algorithm is
order-dependent.

David J.