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: 
 <CAKFQuwYjvVgyw5Ehw8JnPPZ1Tjox_yxktdkw5U8gm8nSM=ejJQ@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>
 <1073004.1597678264@sss.pgh.pa.us>
 <CAKFQuwYjvVgyw5Ehw8JnPPZ1Tjox_yxktdkw5U8gm8nSM=ejJQ@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Mon, 17 Aug 2020 09:07:26 -0700"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <1077716.1597684189.0@sss.pgh.pa.us>
Date: Mon, 17 Aug 2020 13:11:04 -0400
Message-ID: <1077763.1597684264@sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1077716.1597684189.1@sss.pgh.pa.us>

"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Aug 17, 2020 at 8:31 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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'.

Yeah, me either.  So here's a proposed patch, fixing a couple other
things:

* Re-reading this, I thought the use of "preferred" in the existing
footnote about domains could be read as meaning that we treat the
base type as a preferred type; so I changed that.

* Something that's been true for a very long time, but never documented,
is that CASE puts its ELSE clause at the front for this purpose.
I figured that if we're trying to tell the full truth we better mention
that.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="fix-union-type-resolution-doc.patch";
	charset="us-ascii"
Content-ID: <1077716.1597684189.2@sss.pgh.pa.us>
Content-Description: fix-union-type-resolution-doc.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/doc/src/sgml/typeconv.sgml b/doc/src/sgml/typeconv.sgml
index 81dba7dacf..8900d0eb38 100644
--- a/doc/src/sgml/typeconv.sgml
+++ b/doc/src/sgml/typeconv.sgml
@@ -1069,7 +1069,7 @@ domain's base type for all subsequent steps.
     functions, this behavior allows a domain type to be preserved through
     a <literal>UNION</literal> or similar construct, so long as the user =
is
     careful to ensure that all inputs are implicitly or explicitly of tha=
t
-    exact type.  Otherwise the domain's base type will be preferred.
+    exact type.  Otherwise the domain's base type will be used.
    </para>
   </footnote>
 </para>
@@ -1092,24 +1092,29 @@ If the non-unknown inputs are not all of the same =
type category, fail.
 =

 <step performance=3D"required">
 <para>
-Choose the first non-unknown input type which is a preferred type in
-that category, if there is one.
-</para>
-</step>
-
-<step performance=3D"required">
-<para>
-Otherwise, choose the last non-unknown input type that allows all the
-preceding non-unknown inputs to be implicitly converted to it.  (There
-always is such a type, since at least the first type in the list must
-satisfy this condition.)
+Select the first non-unknown input type as the candidate type,
+then consider each other non-unknown input type, left to right.
+  <footnote>
+   <para>
+    For historical reasons, <literal>CASE</literal> treats
+    its <literal>ELSE</literal> clause (if any) as the <quote>first</quot=
e>
+    input, with the <literal>THEN</literal> clauses(s) considered after
+    that.  In all other cases, <quote>left to right</quote> means the ord=
er
+    in which the expressions appear in the query text.
+   </para>
+  </footnote>
+If the candidate type can be implicitly converted to the other type,
+but not vice-versa, select the other type as the new candidate type.
+Then continue considering the remaining inputs.  If, at any stage of this
+process, a preferred type is selected, stop considering additional
+inputs.
 </para>
 </step>
 =

 <step performance=3D"required">
 <para>
-Convert all inputs to the selected type.  Fail if there is not a
-conversion from a given input to the selected type.
+Convert all inputs to the final candidate type.  Fail if there is not an
+implicit conversion from a given input type to the candidate type.
 </para>
 </step>
 </procedure>

------- =_aaaaaaaaaa0--