From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: Pg Docs <pgsql-docs@lists.postgresql.org>
Subject: Re: Inaccurate description of UNION/CASE/etc type selection
In-reply-to: 
 <CAKFQuwY_TRhxKvnf26L0ZQpYm56Y7__WL7GhR0VGg8AX90HTJw@mail.gmail.com>
References: <1019930.1597613200@sss.pgh.pa.us>
 <CAKFQuwbn05z25KPPAwwA+nqvyb_3eqLM+Q4Awu==9bdVJhum8A@mail.gmail.com>
 <1031918.1597624366@sss.pgh.pa.us>
 <CAKFQuwZBS2xjTd2dwkNY-az0KGmYFFnU+ebguD73z7ejgy6D=w@mail.gmail.com>
 <CAKFQuwY_TRhxKvnf26L0ZQpYm56Y7__WL7GhR0VGg8AX90HTJw@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Sun, 16 Aug 2020 18:06:25 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1073003.1597678264.1@sss.pgh.pa.us>
Date: Mon, 17 Aug 2020 11:31:04 -0400
Message-ID: <1073004.1597678264@sss.pgh.pa.us>
Precedence: bulk

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

			regards, tom lane