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

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

> "David G. Johnston" <david.g.johnston@gmail.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.